Why you've struggled with testing
Some common struggles people have with testing, and things you can do to improve.
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. The other day 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 tip for you to take to 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.
P.S. Stay tuned, because over the next couple weeks I’ll share more strategy and tactics for getting your testing skills up to date.
Things to not miss:
- TestingJavaScript.com - This is the huge thing that I wont stop talking about 😉
react-suspense-starter: If you haven’t had a chance to checkout suspense yet and play around with it, check this out :)- DevTipsWithKent - If you haven’t watched any of these yet, I recommend you give them a look. I’m going to be doing some scheduled livestreams soon that you’ll want to catch live for sure!
Some tweets from this last week:
> 🏆 Learn the smart, efficient way to test any JavaScript application. Coming 🔜
>
> Retweet 🔀 and subscribe 💌 to get updates and a special discount!
>
> 🏆🏆🏆🏆🏆🏆🏆🏆🏆🏆
>
> 👉 https://testingjavascript.com/?utm_source=twitter&utm_medium=social&utm_campaign=early-bird … 👈
>
> 🏆🏆🏆🏆🏆🏆🏆🏆🏆🏆
>
> I can’t wait for you to see this. It’s huge.
>
> 
> – Oct 5, 2018
> Friends… I’ve never been more excited about the future of React than I am right now. > > This train has just left the station y’all! 🚂– Oct 7, 2018
> First class API for code splitting built-into React!!! 💯⚛️
>
> YEEEEEEESSSSSSSSSSS!!!!! #ReactJS #FrameworkSummit
>
> 
> Scenario: someone comes to you and laments hope difficult an experience they’re going through is. You’ve been through that and way harder things in your opinion. You can either related and validate or tell them they haven’t even begun to suffer. Your response says much about you. – Oct 3, 2018
This week’s blog post is “Confidently Shipping Code”. It’s the published version of my newsletter from 2 weeks ago. If you thought it was good, go ahead and give it some claps (👏x50) and a retweet:
P.S. If you like this, make sure to subscribe, follow me on twitter, buy me lunch, support me on patreon, and share this with your friends 😀
👋 Hi! I’m Kent C. Dodds. I work at PayPal as a full stack JavaScript engineer. I represent PayPal on the TC39. I’m actively involved in the open source community. I’m an instructor on egghead.io and Frontend Masters. I’m also a Google Developer Expert. I’m happily married and the father of four kids. I like my family, code, JavaScript, and React.