The argument is long ended: You should be testing your mission-critical code.

Everyone accepts that testing code now is better than waiting for users to complain later.

Everyone agrees that the testing should be automated.

Pretty much everyone's had a situation where tests saved them from a production bug...or would have saved them if tests had been in place.

But there's still a struggle. I asked on twitter what you all struggle with around testing. The struggle comes when you're trying to determine what to test, how much time you have to test, what granularity to test, what to mock and what to keep real, or just the daunting task of setting up good testing tools and testing environments. Or the frustration might creep in when you find yourself writing the same code in two places. 🤪

Another big source of frustration with testing — stop us if you've heard this one before — is when you have to basically rewrite your tests every time you touch the code it's testing. Once you pick your head up off your keyboard, you have to ask yourself: "Ok... so why are we testing again? This is just adding friction to shipping code." It's extremely frustrating when you refactor a component and your test breaks. 😡 I wouldn't want to write tests either.

When I got started with testing years ago, I struggled. I struggled hard. I've spent countless hours learning, building, and rebuilding tools. I even gave a full hour talk called "ES6, Webpack, Karma, and Code Coverage". It took a full 60 minutes to explain how to make these tools play nicely together. It took dozens more hours behind the scenes to figure out what I explain in that talk.

But I was committed to figuring out and helping build the best way to do this. I needed it, and I know my fellow developers need it too.

Struggle and frustration don't have to be your experience. You don't have to spend dozens of hours to figure out how to get testing set up in your codebase. I've already done that for you. And the tools have improved, and I can show you how to use them. There are techniques I can teach you that will alleviate the pain and struggle you're having with getting the confidence you're looking for out of your testbase.

Here's a tip for you to take the next time you test your code that'll help you answer the question of "what do I test?" Follow this process:

1. What part of your untested codebase would be really bad if it broke? (The checkout process)
2. Try to narrow it down to a unit or a few units of code (When clicking the "checkout" button a request with the cart items is sent to /checkout)
3. Look at that code and consider who the "users" are (The developer rendering the checkout form, the end user clicking on the button)
4. Write down a list of instructions for that user to manually test that code to make sure it's not broken. (render the form with some fake data in the cart, click the checkout button, ensure the mocked /checkout API was called with the right data, respond with a fake successful response, make sure the success message is displayed).
5. Turn that list of instructions into an automated test.

With the tools and techniques I'm going to show you, this process will become a natural habit. 💯

Stop the struggle. Follow me.