Recently I had an honor of participating in an episode of PodRocket podcast. It was the first ever "PodRocket Mailbag" episode where 3 panelists answered testing questions emailed to the podcast. With me at the recording were Debbie O’Brien and Kent C. Dodds.
You can find the podcast episode here with the full transcript here. Here are some of the questions we were asked and the short summary of our answers:
- Q: "What should devs be focusing on when testing? And what are some basic testing actions devs can take?"
KCD: Mock as little as possible, no shallow rendering. Sometimes it is ok to mock network requests, but in general it is ok if the tests take a little longer, but test the real thing.
- Q: "How can developers get away from testing for test's sake?"
GB: Testing is bad, but there are things worse than testing, like updating Jira issues statuses. Good tests become the status and I would say "if you have good tests, you will spend less time doing the other chores"
DOB: Make testing easy and devs will start doing it more.
- Q: "How can developers get better at mocking during tests?"
GB: I know what Kent would say here, I will write it on a piece paper (writes something)
KCD: Stop mocking "fetch" function and instead mock outside the browser using MSW library.
GB: (turns the piece of paper, it says "MSW" on it). I know you, Kent, so well :)
GB: Less mocking of internal code is good, mock at the boundary of the system, like MSW and Cypress cy.intercept do.
DOB: Good tooling again is the key here. Playwright, Cypress let you do mocking without making the tests dependent on your implementation details.
- Q: "My company only has Manual QA, how do we move towards automation?"
DOB: Try moving away from writing tests (if any) after the implementation is done to writing the tests along the with implementation.
KCD: It is important to understand business needs, I have a blog post Business and Engineering Alignment which explains if you can show the value of testing to achieve the business goals, then testing will be included.
GB: I have a few presentations about bringing automated QA into a large organization. Even inside the organization there are competing priorities and your strategy to add automated tests must address them. Be careful not to alienate manual QA with the prospect of losing jobs to automation.
5: Q: "What are some tips for staying disciplined on writing tests?"
KCD: Make writing a test easy. Write tests once you decide the feature is here to stay. Write tests to try to reproduce a bug.
DOB: Training is important, and it is ok to start with a bad test, it can be improved.
GB: Quality of feedback during testing is important to me. The faster the test can catch the wrong behavior or validate the right one, the better, both while writing it and on CI.
- Q: "Are there ways that devs can make automated tests more effective rather than putting more time and effort into manual testing?"
KCD: The business will be more successful if the tests are automated. If the thing you are testing is here to stay and IS important, it should have an automated test. If a feature or page is temporary, I skip testing and only check it manually once.
DOB: People are resisting changes naturally, so a trial period is a good strategy to let them try new things.
GB: Proof of concept with tests, automating boring parts first, removing load on manual QA.
- Q: "We are testing using Jest, but have troubles configuring the code to even compile"
KCD: I have a blog post to help Common Mistakes with Testing Library.
GB: Look beyond unit testing. Bring a linter, bring TypeScript into your code base to catch common problems early. Use component testing in the browser or even end-to-end tests to simplify setting up the code and avoid problems.
DOB: Yes, we all concentrate on unit tests too much, now end-to-end testing is becoming easier and more powerful to use and avoids all these "import 100 things to test one thing" problem.
- Q: "What are some good tips for actually writing the integration tests after you've already written the unit tests?"
KCD: People worry about over testing and sometimes a single end-to-end test is really covering more than 8 separate unit tests. Also React Testing library is not just for React - there is a flavor of Testing Library for many frameworks and tools.
GB: Make sure to write a deterministic test that knows exactly to expect to find on the test without "if page shows X, then do action Y" conditional logic.
DOB: Don't be afraid to give testing a go. Pick a modern testing tool, the initial experience should be smooth in many cases.
GB: Spend just a little time training before jumping full speed. So many people do not invest enough time to learn the basics of the testing tool and then spend days and days fighting against it.
KCD: If you hit troubles testing, I have a good page that searches across everything I have written and recorded. Here are the search results for testing.
I hope you enjoy the podcast.