JSJ 341: Testing in JavaScript with Gil Tayar
JavaScript Jabber27 Marras 2018

JSJ 341: Testing in JavaScript with Gil Tayar

Panel:
  • Aimee Knight
  • AJ O’Neal
  • Charles Max Wood
Special Guest: Gil Tayar In this episode, the panel talks with Gil Tayar who is currently residing in Tel Aviv and is a software engineer. He is currently the Senior Architect at Applitools in Israel. The panel and the guest talk about the different types of tests and when/how one is to use a certain test in a particular situation. They also mention Node, React, Selenium, Puppeteer, and much more!Show Topics:0:00 – Advertisement: KENDO UI 0:35 – Chuck: Our panel is AJ, Aimee, myself – and our special guest is Gil Tayar. Tell us why you are famous!1:13 – Gil talks about where he resides and his background. 2:27 – Chuck: What is the landscape like now with testing and testing tools now?2:39 – Guest: There is a huge renaissance with the JavaScript community. Testing has moved forward in the frontend and backend. Today we have lots of testing tools. We can do frontend testing that wasn’t possible 5 years ago. The major change was React.The guest talks about Node, React, tools, and more!4:17 – Aimee: I advocate for tests and testing. There is a grey area though...how do you treat that? If you have to get something into production, but it’s not THE thing to get into production, does that fall into product or...what?5:02 – Guest: We decided to test everything in the beginning. We actually cam through and did that and since then I don’t think I can use the right code without testing. There are a lot of different situations, though, to consider.The guest gives hypothetical situations that people could face. 6:27 – Aimee.6:32 – Guest: The horror to changing code without tests, I don’t know, I haven’t done that for a while. You write with fear in your heart. Your design is driven by fear, and not what you think is right. In the beginning don’t write those tests, but...7:22 – Aimee: I totally agree and I could go on and on and on.7:42 – Panel: I want to do tests when I know they will create value. I don’t want to do it b/c it’s a mundane thing. Secondly, I find that some times I am in a situation where I cannot write the test b/c I would have to know the business logic is correct. I am in this discovery mode of what is the business logic? I am not just building your app.I guess I just need advice in this area, I guess.8:55 – Guest gives advice to panelist’s question. He mentions how there are two schools of thought.10:20 – Guest: Don’t mock too much.10:54 – Panel: Are unit tests the easiest? I just reach for unit testing b/c it helps me code faster. But 90% of my code is NOT that.11:18 – Guest: Exactly! Most of our test is glue – gluing together a bunch of different stuff! Those are best tested as a medium-sized integration suite.12:39 – Panel: That seems like a lot of work, though! I loathe the database stuff b/c they don’t map cleanly. I hate this database stuff.13:06 – Guest: I agree, but don’t knock the database, but knock the level above the database.13:49 – Guest: Yes, it takes time! Building the script and the testing tools, but when you have it then adding to it is zero time. Once you are in the air it’s smooth sailing.14:17 – Panel: I guess I can see that. I like to do the dumb-way the first time. I am not clear on the transition.14:47 – Guest: Write the code, and then write the tests.The guest gives a hypothetical situation on how/when to test in a certain situation. 16:25 – Panel: Can you talk about that more, please?16:50 – Guest: Don’t have the same unit – do browser and business logic stuff separated. The real business logic stuff needs to be above that level. First principle is separation of concerns.18:04 – Panel talks about dependency interjection and asks a question. 18:27 – Guest: What I am talking about very, very light inter-dependency interjection.19:19 – Panel: You have a main function and you are doing requires in the main function. You are passing the pieces of that into the components that need it.19:44 – Guest: I only do it when it’s necessary; it’s not a religion for me. I do it only for those layers that I know will need to be mocked; like database layers, etc.20:09 – Panel.20:19 – Guest: It’s taken me 80 years to figure out, but I have made plenty of mistakes a long the way. A test should run for 2-5 minutes max for package.20:53 – Panel: What if you have a really messy legacy system? How do you recommend going into that? Do you write tests for things that you think needs to get tested?21:39 – Guest answers the question and mentions Selenium! 24:27 – Panel: I like that approach.24:35 – Chuck: When you say integration test what do you mean?24:44 – Guest: Integration tests aren’t usually talked about. For most people it’s tests that test the database level against the database. For me, the integration tests are taking a set of classes as they are in the application and testing them together w/o the...so they can run in millisecond time.26:54 – Advertisement – Sentry.io 27:52 – Chuck: How much do the tools matter?28:01 – Guest: The revolutions matter. Whether you use Jasmine or Mocha or whatever I don’t think it matters. The tests matter not the tools.28:39 – Aimee: Yes and no. I think some tools are outdated.28:50 – Guest: I got a lot of flack about my blog where I talk about Cypress versus Selenium. I will never use Jasmine. In the end it’s the29:29 – Aimee: I am curious would you be willing to expand on what the Selenium folks were saying about Puppeteer and others may not provide?29:54 – Guest: Cypress was built for frontend developers. They don’t care about cross browser, and they tested in Chrome. Most browsers are typically the same. Selenium was built with the QA mindset – end to end tests that we need to do cross browser.The guest continues with this topic.30:54 – Aimee mentions Cypress. 31:08 – Guest: My guessing is that their priority is not there. I kind of agree with them.31:21 – Aimee: I think they are focusing on mobile more.31:24 – Guest: I think cross browser testing is less of an issue now. There is one area that is important it’s the visual area! It’s important to test visually across these different browsers.32:32 – Guest: Selenium is a Swiss knife – it can do everything.33:32 – Chuck: I am thinking about different topics to talk about. I haven’t used Puppeteer. What’s that about?33:49 – Guest: Puppeteer is much more like Selenium. The reason why it’s great is b/c Puppeteer will always be Google Chrome. 35:42 – Chuck: When should you be running your tests? I like to use some unit tests when I am doing my development but how do you break that down?36:06 – Guest.38:30 – Chuck: You run tests against production?38:45 – Guest: Don’t run tests against production...let me clarify!39:14 – Chuck.39:21 – Guest: When I am talking about integration testing in the backend...40:37 – Chuck asks a question. 40:47 – Guest: I am constantly running between frontend and backend.I didn’t know how to run tests for frontend. I had to invent a new thing and I “invented” the package JS DONG. It’s an implementation of Dong in Node. I found out that I wasn’t the only one and that there were others out there, too.43:14 – Chuck: Nice! You talked in the prep docs that you urged a new frontend developer to not run the app in the browser for 2 months?43:25 – Guest: Yeah, I found out that she was running the application...she said she knew how to write tests. I wanted her to see it my way and it probably was a radical train-of-thought, and that was this...44:40 – Guest: Frontend is so visual.45:12 – Chuck: What are you working on now?45:16 – Guest: I am working with Applitools and I was impressed with what they were doing.The guest goes into further detail.46:08 – Guest: Those screenshots are never the same.48:36 – Panel: It’s...comparing the output to the static site to the...48:50 – Guest: Yes, that static site – if you have 30 pages in your app – most of those are the same. We have this trick where we don’t upload it again and again. Uploading the whole static site is usually very quick. The second thing is we don’t wait for the results. We don’t wait for the whole rendering and we continue with the

Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

Jaksot(735)

JSJ 308: D3.js with Ben Clinkinbeard

JSJ 308: D3.js with Ben Clinkinbeard

Panel: Joe EamesCory HouseAimee Knight Special Guests: Ben ClinkinbeardIn this episode, the JavaScript Jabber panelists talk about D3.js with Ben Clinkinbeard. D3.js is a JavaScript library that has you use declarative code to tell it what you want and then it figures out all of the browser inconsistencies and creates the notes for you. He talks about the two main concepts behind D3, scales and selections, which once you understand make D3 a lot more user friendly. He then touches on SPGs and discusses his Learn D3 in 5 Days course.In particular, we dive pretty deep on:What is D3.js?Stands for Data Driven DocumentsJavaScriptHow much of the learning curve is attributed to learning D3?SPG2 main concepts behind D3: scales and selectionsIs learning about SPGs a prerequisite to leaning D3?How serious are you talking when saying idiosyncrasies?SPG tagUnderstanding positioning in SPGPositions with CSS transformsAre you required to use SPG?Not required to use SPG with D3CanvasSPG is vector basedSPG utility functionResponseivefyLearn D3 in 5 Days courseIs there and overlap with D3 and React?And much, much more!Links:D3.jsJavaScriptResponsivefyLearn D3 in 5 Days courseReact @bclinkinbeardBen’s GitHubPicks:CoryReact cheat sheet“Why software engineers disagree about everything” by Haseeb QureshiJoe Eames“JavaScript vs. TypeScript vs. ReasonML” by Dr. Axel RauschmayerAimee“How To Use Technical Debt In Your Favor”Neuroscience News TwitterBenComLinkSupport this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

10 Huhti 201845min

JSJ 307: Apollo with Peggy Rayzis

JSJ 307: Apollo with Peggy Rayzis

Panel: Charles Max WoodAimee KnightAJ ONeal Special Guests: Peggy RayzisIn this episode, the JavaScript Jabber panelists talk about Apollo with Peggy Rayzis. Peggy is an open source engineer on the Apollo team where she primarily focuses on client stuff, working on Apollo Client, and also other libraries. Previously, she was a UI engineer at Major League Soccer where she worked primarily with React and React Native. She discusses what GraphQL is and how it is used, as well as how they use it in the Apollo team to make their lives as developers easier. They also touch on when it would work best to use GraphQL and when it is not ideal to use it.In particular, we dive pretty deep on:AiA 127 EpisodePeggy introWhat is GraphQL?What is a Typed Query Language?What is a schema?Where do schemas get defined?GraphQL SDLApollo Stack and Apollo ServerTracing and cash controlApollo EngineHow GraphQL Replaces ReduxGraphQL cuts down on front-end managementApollo Link StateThe best code is no codeApollo Client allows for greater developer productivityDoes the conversation change if you’re not using Redux or in a different ecosystem?When is the right time to use this?Data doesn’t have to be graph shaped to get the most out of GraphQLAnalyze schema with Apollo EngineIs there a way to specify depth?Max Stoiber blog postHow would people start using this?HowtoGraphQL.comAnd much, much more!Links:React Dev SummitJS Dev SummitApolloAiA 127 EpisodeApollo ClientMajor League SoccerReactReact NativeGraphQLGraphQL SDLApollo ServerApollo EngineHow GraphQL Replaces ReduxApollo Link StateReduxMax Stoiber blog postHowtoGraphQL.com@PeggyRayzisPeggy’s GitHubPeggy’s MediumPicks:CharlesGraphQL RubyWordPress GraphQLHogwarts Battles Board GamePandemic LegacyRisk LegacyAimeeHow GraphQL Replaces ReduxJavaScript Meetup in LAAJSimple.comBroccoliWallet.comThe Four by Scott GallowayPeggyWorkshop.meThanks for the Feedback by Douglas StoneSupport this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

3 Huhti 201840min

JSJ 306: The Framework Summit with Joe Eames

JSJ 306: The Framework Summit with Joe Eames

Panel: Charles Max WoodCory HouseAimee KnightJoe EamesAJ O'NealIn this episode, the JavaScript Jabber panelists talk about the Framework Summit. It was the brainchild of Merrick Christensen. This summit includes talks on multiple different frameworks all in a two-day conference, which allows you to get exposed to new frameworks while still learning more about the framework your job requires you to use. Another goal of the conference is that it will be able to open people’s eyes up to the different frameworks available to them and show that no one framework is superior to another.In particular, we dive pretty deep on:What is the Framework Summit?The framework you use plays a huge role in your programmingFor people who want to learn about more than one frameworkAllows you to exploreThe format of the conferencePark City, Utah in October 2018Helps you answer which framework should you use?Goal is to open people’s eyes up to other frameworksDecrease internet arguments over which framework is betterFluent ConferenceGet to have conversation with other people who work in your frameworkMaking connectionsReact Rally Talk Evan CzaplickiThe context mattersBeing able to deep dive into the different frameworksUsing frameworks in conjunction with one anotherHave you seen “religionist” themes in programming frameworks?Why Good People Are Divided by Politics and Religion by Jonathan HaidtSome people will never look beyond their frameworksIf it’s working, why would you mess with it?And much, much more!Links:React Dev SummitJS Dev SummitFramework SummitAngularReactEmberJavaScriptFluent ConferenceReact Rally Talk Evan CzaplickiWhy Good People Are Divided by Politics and Religion by Jonathan Haidt@FrameworkSummitPicks:CharlesParked Out By the Lake Dustin ChristensenDevChat.tvNewspaper by ThemeforestCoryQuokkaAimeeRepublic of Tea – Apple Cider Vinegar TeaThe Way of TestivusJoeEvan Czaplicki TalkAJDinosaursCough Syrup by Young the GiantSupport this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

27 Maalis 201848min

JSJ 305: Continuous Integration, Processes, and DangerJS with Orta Therox

JSJ 305: Continuous Integration, Processes, and DangerJS with Orta Therox

Panel: Charles Max WoodAimee KnightJoe EamesAJ O'Neal Special Guests: Orta TheroxIn this episode, the JavaScript Jabber panelists talk about the tool Danger with Orta Therox. Danger allows you to create cultural rules about your pole request workflow. They discuss what Danger is, how it works, and how it can help you to catch errors and speed up code review. Danger lets you erase discussions so that you can focus on the things that you should really be focusing on, like the code. They also compare Danger to other ways of doing test converge.In particular, we dive pretty deep on:What is DangerJS?Think of it as being on the PR levelProvides an eval contextUsed on larger projectsReact, React Native, Apollo, and RxJSExperimenting with moving Danger onto a serverDanger can run as a linting stepPre-commit hooksPrettierHow do you use Danger on your own machine?Danger Ruby vs Danger JSNPM installHow is using Danger better that other ways of test coverage?What kinds of rules can you write for this system?Can use with Ruby or JavaScriptReact StorybooksRetrospectivesAnd much, much more!Links:React Dev SummitJS Dev SummitDanger JSReactReact NativeApolloRxJSPrettierDanger RubyRubyJavaScriptOrta’s GitHubArtsy BlogPicks:CharlesHogwarts Battle Board GameSushi Go Party! GameNYC tipsAimeeMax Stoiber BlogThe Ultimate Guide to Kicking Ass on Take-home Coding ChallengesJoeSaltCONStuffed Fables Board GameAJUniFi AC LiteFullmetal AlchemistOrtaThe WireWorm Web SerialSupport this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

20 Maalis 201848min

JSJ 304: React: The Big Picture

JSJ 304: React: The Big Picture

Panel: Charles Max WoodAimee KnightJoe EamesCory HouseAJ O'Neal Special Guests: NoneIn this episode, the JavaScript Jabber panelists talk about React: The Big Picture, Cory’s course on Pluralsight and what React is all about. They discuss both the pros and cons when it comes to using React and when it would be the best to use this library. They also encourage programmers to use React in a more consistent way so that people can share components.In particular, we dive pretty deep on:What is React: The Big Picture course?ReactThe frameworks work with each otherReason and ElmHow to decide when using React is the best option?React tradeoffsJavaScriptReact expects you to do a little more typing and workReact is very close to JavaScriptReact pushes you towards a single file per componentReact Round UpAre the Code Mods as wonderful as they sound?AngularCreate React AppWhat are Code Mods?Lack of opinionated approach in ReactUsing React in a more consistent wayMobX and ReduxStart off using just plain ReactWhen wouldn’t you want to use React?And much, much more!Links:React: The Big PictureCory’s PluralsightReasonElmReactJavaScriptReact Round UpCreate React AppAngularMobXReduxFramework Summit 2018Angular: The Big PictureReact Dev SummitPicks:CharlesHunting HitlerThe Greatest Showman: Sing-a-longAimee“Why being a perfectionist is an obstacle (and how to beat it)” by Gui Fradin“How to understand the large codebase of an open-source project?” blog postJoeMarital Bliss Card GameAJPplwink.comSupport this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

13 Maalis 201851min

JSJ 303: Test Coverage Tools with Ben Coe, Aaron Abramov, and Issac Schleuter

JSJ 303: Test Coverage Tools with Ben Coe, Aaron Abramov, and Issac Schleuter

Panel: Charles Max WoodAimee KnightCorey HouseAJ O'Neal Special Guests: Ben Coe, Aaron Abramov, and Issac SchleuterIn this episode, the JavaScript Jabber panelists talk with Ben Coe, Aaron Abramov, and Issac Schleuter about test coverage and testing tools. They talk about the different tools and libraries that they have contributed to the coding community, such as NYC, conf, and Jest. They also discuss what test coverage is actually about and when using test coverage tools is necessary.In particular, we dive pretty deep on:What have you contributed to the testing tools community?npmNYC tool and instanbul projectconfJestThese libraries were developed to be easy and have “batteries included”False positives with test coverageEncourage testing practices that don’t practice in a superficial wayTest coverage is about making sure you test every state a public API can get intoThink through the test you’re writing firstBarriers against testingDon’t spike the code too quicklyProvides guardrails for newer developers to contribute to open source projectsUse tests to understand the systemHow to spend your time betterWhen you need testsValue is very short termTDDAnd much, much more!Links:@BenjaminCoe@AaronAbramov_Issac’s GitHubPicks:CharlesReact RoundupViews on VueAdventures in AngularReact Dev Summit 2018AimeeGalentine’s DayDnote CLIAJThe Hero of Ages by Brandon SandersonCoreyWe are hive project guidelinesTip: You can install node as a dependency on your projectBenHack Illinois 2018C8AaronReasonIssacThe Tap 100Krypton AppFriendly Fire PodcastsSupport this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

6 Maalis 201822min

JSJ 302: Evaluating Web Frameworks with Kitson Kelly

JSJ 302: Evaluating Web Frameworks with Kitson Kelly

Panel: Charles Max WoodAimee KnightAJ O'Neal Special Guests: Kitson KellyIn this episode, the JavaScript Jabber panelists talk with Kitson Kelly about evaluating web frameworks. Kitson is currently in Australia working for ThoughtWorks as a principle technologist. He has written many articles on frameworks and urges that people don’t get stuck on one framework in their programming. He talks about how using only frameworks that you know could hurt you in the long run. This episode is great for understanding when to use certain JavaScript frameworks and how branching out from what is comfortable might make your job easier.In particular, we dive pretty deep on:Articles on web frameworksHow do you pick a JavaScript framework to use?The framework depends on your changing needsRecommending less popular frameworksAngular, Ember, ReactReact vs ReduxCertain domains with different frameworks?Each framework takes a different approachHow to decide which framework to use?Only give it a couple days to see if your app works with the frameworkIs it ever appropriate to not use a certain framework?Frameworks are there to make your job easierDon’t be afraid to try new frameworksChoose a framework that will “be there tomorrow”What is the future for frameworks?Experiment and be honest with what you needAnd much, much more!Links:LinodeThoughtWorksKendo UILootCrate@KitsonKKitson’s GitHubPicks:CharlesFacebookThe 12 Week Year by Brian P. MooreGoogle Drive for BusinessAimeeWould College Students Retain More If Professors Dialed Back The Pace?URL to PDF ConverterCSS HistoryAJTylenol Cold and Flu SevereKitsonMicrosoft AzureZypeSupport this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

27 Helmi 201853min

JSJ 301: CSS Grids: The Future of Frontend Layout with Dave Geddes

JSJ 301: CSS Grids: The Future of Frontend Layout with Dave Geddes

Panel: Charles Max WoodAimee KnightCory HouseAJ O'NealJoe EamesAaron Frost Special Guests: Dave GeddesIn this episode, the JavaScript Jabber panelists talk with Dave Geddes about CSS Grids. Dave quit his job about a year ago and has been living the entrepreneur and programmer life since then. Now, he builds mastery games to help people learn CSS. Dave discusses the differences between Flexbox and CSS Grid and how the games that he creates can help people learn CSS Grid in a fun and interactive way.In particular, we dive pretty deep on:CSS Mastery gamesFlexboxZombies.comGridCritters.comUses spaced repetition and delayed recall to learnCSS GridFlexboxCSS Grid as the cake and Flexbox as the frostingEdge specWhat Flexbox can doSub-GridsGeddski.comNesting GridsOld Grid vs New Grid layoutWhy would you move from Flexbox to CSS Grid?CSS Grid toolsGridByExample.comEducation and GamificationPick a UI that interests youFor a discount on Grid Critters: enter JS Jabber for 20% offAnd much, much more!Links:LinodeFlexboxZombies.comGridCritters.comGeddski.comGridByExample.comFreshBooks@GeddskiPicks:CharlesR Pods EarphonesAimeeNEU Cleanse“At Age 6, Girls Are Less Likely to Identify Females As ‘Really, Really Smart’”CoryCory TweetAJHow to Start a StartupMade in America by Sam WaltonJoeThe Dungeoneers by John David AndersonNG ConfAaronFire and Fury by Michael WolffDaveThey Are BillionsSupport this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

20 Helmi 20181h 3min

Suosittua kategoriassa Liike-elämä ja talous

sijotuskasti
psykopodiaa-podcast
mimmit-sijoittaa
rss-rahapodi
ostan-asuntoja-podcast
rss-lahtijat
pomojen-suusta
taloudellinen-mielenrauha
rahapuhetta
io-techin-tekniikkapodcast
oppimisen-psykologia
rss-seuraava-potilas
inderespodi
kasvun-kipuja
sijoituspodi
hyva-paha-johtaminen
rss-markkinointiradio
leadcast
kultaiset-hoitajat
rss-rikasta-elamaa