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:
- What part of your untested codebase would be really bad if it broke? (The
checkout process) - 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) - Look at that code and consider who the “users” are (The developer rendering
the checkout form, the end user clicking on the button) - 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). - 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.
