Podcasts about react testing

In the latest episode of Test Automation Experience, hosted by Nikolay Advolodkin, we had the pleasure of delving into testing React using React Testing Library with Daniel Afonso. The conversation covered the transition from traditional testing approaches to the adoption of the React Testing Library, a shift that introduced speed and a new focus on user perspective. Daniel shared his personal journey of migrating tests, which led to the scrubbing of superfluous tests and a newfound appreciation for quality assurance as part of the development pipeline. The episode includes a hands-on demonstration where Daniel troubleshoots a real-time React test setup while emphasizing the principles of the testing library—avoiding implementation details and ensuring accessibility for all users. With topics ranging from firing events to harnessing asynchronous utilities, the podcast provides valuable takeaways for any developer looking to refine their testing skills. Daniel also touches on his React Testing Library course offered on egghead IO, promising a concise yet comprehensive guide through a series of 22 lessons in just 25 minutes. Check out his course linked below for a deeper understanding of rendering, querying, and event firing, aiming to bolster both efficiency and quality in testing practices!CONNECT WITH DANIEL AFONSO

Kent C Dodds is a software engineer, entrepreneur and educator from Utah, USA. Kent joins Cameron on The Coder Career to discuss his original journey into tech, lessons he has learnt and what he predicts for his future, as well as his opinions around the best method and stack to learn (through his Epic Web course).Get in touch with Kent:TwitterEpic Web CourseGet in touch with CamTwitterYouTube Hosted on Acast. See acast.com/privacy for more information.

Kent C Dodds is a software engineer, entrepreneur and educator from Utah, USA. Kent joins Cameron on The Coder Career to discuss his original journey into tech, lessons he has learnt and what he predicts for his future, as well as his opinions around the best method and stack to learn (through his Epic Web course).Get in touch with Kent:TwitterEpic Web CourseGet in touch with CamTwitterYouTube Hosted on Acast. See acast.com/privacy for more information.

Should we assert on props.onClick while writing test cases in react-testing-library?Testing Implementation DetailsAsserting props.onClick in react-testing-library

Can I test drag and drop with React Testing library?

So I have a MainComponent, inside there are some “remote” components like OfficeSelect, that fetches data asynchronously on mount, using axios, everytime I test MainComponent I get the “act” warning on that OfficeSelect fetch, how do I deal with that?Fix the “not wrapped in act(…)” warning

In this episode of GeeksBlabla we discuss, React, How to get started ,Core concepts, React Ecosystem and a lot of topics around it. Guests Yassine ElOuafi Youssouf EL Azizi Amine Hakkou Notes 0:00 - Introduction and welcoming 0:05 - What is React? && React History. 0:09 - How is React different from other solution such as jquery/angular and Vuejs 0:19 - Imperative and Declarative in React? 0:22 - What do I need To know to start working with React? 0:31 - React Fundamental : JSX. 0:38 - Deference between JSX and template system. 0:41 - React Fundamental : Components, State, Props. 0:48 - React Patterns: HOC, render props, Compound components 0:52 - State Management Approaches. 1:03 - React and Typescript. 1:12 - Redux-saga vs Redux-thunk 1:14 - React Fiber, Virtual Dom, Reconciliation, concurrent mode. 1:34 - React Suspense && algebraic effects. 1:48 - Preact. 1:58 - WebAssembly and React. 2:04 - Styling in React. 2:08 - Server side Rendering with React. 2:12 - Meta-frameworks : Next.js / Gatsby. 2:25 - React Testing. 2:33 - Tools and Resources. Links React Yassine Blog Kent C. Dodds React Testing Library The Beginner's Guide to React Prepared and Presented by : Soufian El Foukahi Youssouf EL Azizi

#732 (https://github.com/kentcdodds/ama/issues/732)

Today Enzyme is a standard library for writing tests in React. But there is also a new player – react-testing-library. The presentation is a comparison of Enzyme and react-testing-library, which aims to make testing more accessible, predictable and user-oriented. Let’s cover their philosophical differencies, getting false results and misuse of patterns. Presenter: Denis Bakhmutov

Today Enzyme is a standard library for writing tests in React. But there is also a new player – react-testing-library. The presentation is a comparison of Enzyme and react-testing-library, which aims to make testing more accessible, predictable and user-oriented. Let’s cover their philosophical differencies, getting false results and misuse of patterns. Presenter: Denis Bakhmutov

In this episode, Chris & Spencer discuss testing our design system components with react-testing-library and the recent news of Yarn being rewritten in TypeScript (along with other features and changes). Show Notes Yarn's Future - v2 and beyond Mocha Chai Enzyme Rubber Ducking Publication on Medium react-testing-library Jest RRU 043: Testing React Apps Without Testing Implementation Details with Kent C. Dodds Capybara Mocking CSS Modules with Jest

Panel: Lucas Reis Justin Bennett Charles Max Wood Special Guest: Kent C. Dodds In this episode, the panelist talk with today’s guest, Kent C. Dodds who works for PayPal, is an instructor, and works through open source! Kent lives in Utah with his wife and four children. Kent and the panel talk today about testing – check it out! Show Topics: 0:00 – Kendo UI 0:32 – Chuck: Hello! My new show is TheDevRev – please go check it out! 1:35 – Panel: I want all of it! 1:43 – Chuck: Our guest is Kent C. Dodds! You were on the show for a while and then you got busy. 2:06 – Guest.  3:09 – Panel: The kid part is impressive. 3:20 – Guest: Yeah it’s awesome, but the kid part is my wife!  4:09 – Panel: 10 years ago we weren’t having any tests and then now we are thinking about how to write better tests. It’s the next step on that subject. What is your story with tests and what sparked these ideas? 4:50 – Guest. 7:25 – Panel: We have a bunch of tests at my work. “There is no such thing as too many tests” are being said a lot! Then we started talking about unit tests and there was this shift. The tests, for me, felt cumbersome. How do I know that this suite of tests are actually helping me and not hurting me? 8:32 – Guest: I think that is a valuable insight. 11:03 – Panel: What is the make-up of a good test? 11:13 – Guest: Test every line – everything! No. 11:19 – Chuck: “Look at everything!” I don’t know where to start, man! 11:30 – Guest: How do you avoid those false negatives and false positives. 15:38 – Panel: The end user is going to be like more of integration test, and the developer user will be more like a unit tester? 16:01 – Guest: I don’t care too much of the distinction between unit and integration tests. 18:36 – Panel: I have worked in testing in the past. One of the big things that fall on the users’ flow is that it’s difficult b/c maybe a tool like Selenium: when will things render? Are you still testing things in isolation? 19:33 – Guest: It depends. When I talk about UI integration testing I am still mocking the backend. 23:10 – Chuck: I am curious, where do you decide these are expensive (so I don’t want to do too many of them), but at what point is it worth it to do it? 23:30 – Guest mentions the testing pyramid. 28:14 – Chuck: Why do you care about confidence? What is confidence and what does it matter? 28:35 – FreshBooks! 29:50 – Guest. 32:20 – Panel: I have something to add about the testing pyramid. Lucas talks about tooling, Mocha, JS Dong, and more! 33:44 – Guest: I think the testing pyramid is outdated and I have created my own. Guest talks about static testing, LINT, Cypress, and more! 35:32 – Chuck: When I was a new developer, people talked about using tests to track down bugs. What if it’s a hairy bug? 36:07 – Guest: If you can, you can use this methodical approach... 39:46 – Panel: Let’s talk about the React library for a little bit? Panel: Part of the confidence of the tests we write we ask ourselves “will it stand the test of time?” How does the React Testing library go about to solve that? 41:05 – Guest. 47:51 – Panel: A few more questions. When you are getting something and testing and grabbing the label by its text have you found that to be fragile? Is it reasonably reliable? 48:57 – Guest: Yeah this is a concern and it relies on content. 53:06 – Panel: I like this idea of having a different library. Sometimes we think that a powerful tool is better, but after spending some time with other tools that’s not always the case. 54:16 – Guest: “You tie your hands to free your mind.” It does less but what it does less it does better. 55:42 – Panel: I think that with Cypress, too? 55:51 – Guest: Yeah that’s why Cypress is great to use. 57:17 – Panel: I wrote a small library here at work and it deals with metrics. I automated all of those small clicks – write a bit – click a bit – and it was really good. I felt quite efficient. Those became the tests. 57:58 – Panel: One more question: What about react Native? That comes up a lot. At looking at testing libraries we try to keep parody between the two. Do you have any thoughts on that? 58:34 – Guest talks about React Native. 1:00:22 – Panel: Anything else? It’s fascinating to talk about and dive-into these topics. When we talk about confidence that is very powerful, too. 1:01:02 – Panelist asks the last question! 1:01:38 – Guest: You could show them the coverage support. Links: Ruby on Rails Angular JavaScript Elm Phoenix GitHub Get A Coder Job Enzyme React Testing Library Cypress.io Hillel Wayne Testing JavaScript with Kent C. Dodds Kent Dodds’ News Kent Dodds’ Blog Egghead.io – Kent C. Dodds Ready to Write a Novel? Practical TLA+ GitHub: Circleci-queue GitHub: sstephenson / bats Todoist Discord Kent’s Twitter Sponsors: Get a Coder Job Cache Fly Fresh Books Kendo UI   Picks: Lucas Hillel Wayne Practical TLA+ Justin Circle CI Queue Bats Todoists Charles MFCEO Project Podcast The DevRev Kent Discord Devs Who Write Finding your Why! TestingJavaScript.com kcd.im/news kcd.i./hooks-and-suspense NaNoWriMo

Panel: Lucas Reis Justin Bennett Charles Max Wood Special Guest: Kent C. Dodds In this episode, the panelist talk with today’s guest, Kent C. Dodds who works for PayPal, is an instructor, and works through open source! Kent lives in Utah with his wife and four children. Kent and the panel talk today about testing – check it out! Show Topics: 0:00 – Kendo UI 0:32 – Chuck: Hello! My new show is TheDevRev – please go check it out! 1:35 – Panel: I want all of it! 1:43 – Chuck: Our guest is Kent C. Dodds! You were on the show for a while and then you got busy. 2:06 – Guest.  3:09 – Panel: The kid part is impressive. 3:20 – Guest: Yeah it’s awesome, but the kid part is my wife!  4:09 – Panel: 10 years ago we weren’t having any tests and then now we are thinking about how to write better tests. It’s the next step on that subject. What is your story with tests and what sparked these ideas? 4:50 – Guest. 7:25 – Panel: We have a bunch of tests at my work. “There is no such thing as too many tests” are being said a lot! Then we started talking about unit tests and there was this shift. The tests, for me, felt cumbersome. How do I know that this suite of tests are actually helping me and not hurting me? 8:32 – Guest: I think that is a valuable insight. 11:03 – Panel: What is the make-up of a good test? 11:13 – Guest: Test every line – everything! No. 11:19 – Chuck: “Look at everything!” I don’t know where to start, man! 11:30 – Guest: How do you avoid those false negatives and false positives. 15:38 – Panel: The end user is going to be like more of integration test, and the developer user will be more like a unit tester? 16:01 – Guest: I don’t care too much of the distinction between unit and integration tests. 18:36 – Panel: I have worked in testing in the past. One of the big things that fall on the users’ flow is that it’s difficult b/c maybe a tool like Selenium: when will things render? Are you still testing things in isolation? 19:33 – Guest: It depends. When I talk about UI integration testing I am still mocking the backend. 23:10 – Chuck: I am curious, where do you decide these are expensive (so I don’t want to do too many of them), but at what point is it worth it to do it? 23:30 – Guest mentions the testing pyramid. 28:14 – Chuck: Why do you care about confidence? What is confidence and what does it matter? 28:35 – FreshBooks! 29:50 – Guest. 32:20 – Panel: I have something to add about the testing pyramid. Lucas talks about tooling, Mocha, JS Dong, and more! 33:44 – Guest: I think the testing pyramid is outdated and I have created my own. Guest talks about static testing, LINT, Cypress, and more! 35:32 – Chuck: When I was a new developer, people talked about using tests to track down bugs. What if it’s a hairy bug? 36:07 – Guest: If you can, you can use this methodical approach... 39:46 – Panel: Let’s talk about the React library for a little bit? Panel: Part of the confidence of the tests we write we ask ourselves “will it stand the test of time?” How does the React Testing library go about to solve that? 41:05 – Guest. 47:51 – Panel: A few more questions. When you are getting something and testing and grabbing the label by its text have you found that to be fragile? Is it reasonably reliable? 48:57 – Guest: Yeah this is a concern and it relies on content. 53:06 – Panel: I like this idea of having a different library. Sometimes we think that a powerful tool is better, but after spending some time with other tools that’s not always the case. 54:16 – Guest: “You tie your hands to free your mind.” It does less but what it does less it does better. 55:42 – Panel: I think that with Cypress, too? 55:51 – Guest: Yeah that’s why Cypress is great to use. 57:17 – Panel: I wrote a small library here at work and it deals with metrics. I automated all of those small clicks – write a bit – click a bit – and it was really good. I felt quite efficient. Those became the tests. 57:58 – Panel: One more question: What about react Native? That comes up a lot. At looking at testing libraries we try to keep parody between the two. Do you have any thoughts on that? 58:34 – Guest talks about React Native. 1:00:22 – Panel: Anything else? It’s fascinating to talk about and dive-into these topics. When we talk about confidence that is very powerful, too. 1:01:02 – Panelist asks the last question! 1:01:38 – Guest: You could show them the coverage support. Links: Ruby on Rails Angular JavaScript Elm Phoenix GitHub Get A Coder Job Enzyme React Testing Library Cypress.io Hillel Wayne Testing JavaScript with Kent C. Dodds Kent Dodds’ News Kent Dodds’ Blog Egghead.io – Kent C. Dodds Ready to Write a Novel? Practical TLA+ GitHub: Circleci-queue GitHub: sstephenson / bats Todoist Discord Kent’s Twitter Sponsors: Get a Coder Job Cache Fly Fresh Books Kendo UI   Picks: Lucas Hillel Wayne Practical TLA+ Justin Circle CI Queue Bats Todoists Charles MFCEO Project Podcast The DevRev Kent Discord Devs Who Write Finding your Why! TestingJavaScript.com kcd.im/news kcd.i./hooks-and-suspense NaNoWriMo

In this episode Wes and Scott discuss specialization vs generalization - the different ways one can be a generalist or a specialist, advantages and disadvantages to both, and, ultimately, which is the better career path. Freshbooks - Sponsor Get a 30 day free trial of Freshbooks at freshbooks.com/syntax and put SYNTAX in the “How did you hear about us?” section. Dev Lifts — Sponsor Dev Lifts - Thad and JC are on a mission to make web developers healthy. They’re currently offering Personal Training and Nutrition Plans as well as a new program called Fit.Start. Get 50% off with the coupon code “tasty”. Check it out today! Show Notes 4:18 - What is a specialist? Someone who is very good at one or two things Can be very lucrative if you’ve taken the time to become well-known in you’re industry 12:20 - What is a generalist? Two ways to look at generalists: Someone who tries to do a little bit of everything (e.g. a developer who does Wordpress, Drupal, Django, Rails, etc.) Someone who builds related skills around one area (e.g. a JavaScript developer who can code up a backend and a frontend) There will be more jobs available for the dev with tightly integrated skills in related areas than a true “jack of all trades”. 22:22 - Frontend vs Backend Frontend Frameworks (React, Vue, etc.) CSS Performance Animations Backend Web servers Serverless / AWS Scaling Frameworks Performance Databases Docker CI 26:50 - When to widen your focus When you are complacent with your mastery You need a skill to get something done. For fun For a specific job 30:42 - When to narrow your focus You don’t feel control over your skills You are missing out on employment because a lack of skills in one department You feel overwhelmed by the options available You want to be the "go to person” For fun 35:48 - How to master and expand Focus on one skill at at time. Master it and then expand on your skillset Find satellite skills - things that work in harmony 38:47 - Scott’s journey 42:31 - Wes’ journey 44:55 - How to know where to focus Necessity will dictate a lot - what do you need right now? Job postings - you can stack the deck in your favor by learning React. Once you are in, you’re can lean anything you want. Follow your heart - but have a plan 51:03 - Should I be a generalist or a specialist? Wes: There is nothing wrong with having a large skillset as long as you aren’t mediocre at everything. If you’re optimizing for hire-ability I think having a defined focus on either front-end or back-end is best, but still an understanding of how the other works. Ideally you have 1) Very good JS skills, 2) an understanding of how things work on both ends. Scott: You can do either, but whatever you do, do it well. It’s easier to do a few things well than many things well. That said there are some virtuosic devs out there who can be amazing at many things, however those people are not common. Most people have holes in their armor. Links JAMstack_conf ××× SIIIIICK ××× PIIIICKS ××× Scott: Great British Baking Show Wes: 1 Pointless Packaging Instagram / 2 Ozark Season 2 Shameless Plugs Scott’s React Testing for Beginners Course Wes’ Advanced React Course Tweet us your tasty treats! Scott’s Instagram LevelUpTutorials Instagram Wes’ Instagram Wes’ Twitter Wes’ Facebook Scott’s Twitter Make sure to include @SyntaxFM in your tweets

In this episode Wes and Scott discuss 11 habits that will make you a better developer - everything from understanding the business goals behind your projects to maintaining work-life balance, staying curious, and developing empathy. Freshbooks - Sponsor Get a 30 day free trial of Freshbooks at freshbooks.com/syntax and put SYNTAX in the “How did you hear about us?” section. Sanity.io - Sponsor Sanity.io is a real-time headless CMS with a fully customizable Content Studio built in React. Get up and running by typing npm i -g @sanity/cli && sanity init in your command line. Get an awesome supercharged free developer plan on sanity.io/syntax. Show Notes 2:55 - You understand stakeholder and business goals What is the website (or project) ultimately trying to accomplish? How does the business make money? Don’t get caught up in your own “mama drama” about frameworks, but instead focus on how a particular framework will help achieve the end goal of the business 5:13 - You’re curious and always learning This industry is ever-changing and isn’t slowing down 7:36 - You have an open mind about new technology Don’t “poopoo” something because it’s intimidating, new, scary or different Like foods you’ve never tried, sometimes something unusual turns out to be game changing 9:57 - You ask for help #LifeHack - most people know more than you Be comfortable with NOT knowing Be comfortable with failing and with how others might perceive that Check your ego at the door 15:35 - You help others Helping others solidifies your own knowledge Answering questions Stack Overflow Quora Blogging YouTube videos Mentoring co-workers Not offering unwanted advice 19:12 - You have a “problem solver” mentality General curiosity - figuring out why things aren’t working Break things down into testable components to pinpoint an issue Have a clear head under pressure (e.g. interviews) 24:37 - You have fun with what you do Enjoying challenges Even if something isn’t particularly fun, you find ways to make it fun and interesting 27:54 - You understand work-life balance Burnout is huge in our industry It can be difficult when you love what you do, but it’s so important to maintain balance 34:00 - You are empathetic to your co-workers and users Be a team players while getting things done Make everyone around you better at what they do Be someone others want to work with by being inclusive and professional Don’t make inappropriate jokes, put co-workers in a tough position, etc. 37:08 - You pay attention to detail Think about edge cases 39:03 - You’re part of the community Local meetups / lunch and learn Twitter #100daysofcode Conferences ××× SIIIIICK ××× PIIIICKS ××× Scott: Overcooked! 2 Wes: Book - Rich Dad Poor Dad Shameless Plugs Scott’s React Testing for Beginners Course Wes’ Advanced React Graph QL Course Tweet us your tasty treats! Scott’s Instagram LevelUpTutorials Instagram Wes’ Instagram Wes’ Twitter Wes’ Facebook Scott’s Twitter Make sure to include @SyntaxFM in your tweets

Ovidiu Chereches talks with us about React Cosmos & React Testing

Ovidiu Chereches talks with us about React Cosmos & React Testing

I had a friend send me this testing code: describe('handleChangeStatusConditionSearchText', () => { test('should handle changing status search text within FormWizard', () => { const wrapper = shallow(); const state = { ...wrapper.instance().state, statusConditionSearchText: 'poop' }; wrapper.instance().handleChangeStatusConditionSearchText('poop'); expect(wrapper.instance().state).toEqual(state); }); }); And I had a few concerns with it, so I decided to record my thoughts :) (Learn more about enzyme (https://github.com/airbnb/enzyme) and shallow rendering (https://github.com/airbnb/enzyme/blob/f3bbfd3c2b1ae5c09d50fa0429d0dd599d3bbe82/docs/api/shallow.md), and then never shallow render again...