UI Testing Myths
Some common myths around testing and what the reality is…
Today is my birthday!!!
I’m celebrating a few ways. First, I invited folks on Twitter to do two things:
- Perform a random act of kindness for someone today (can be anonymous but doesn’t have to be). I’d love to hear what you did!
- Give testingjavascript.com a look/share 🏆
💚💜💙
Please join in (if you haven’t already)!
(Speaking of big days, tomorrow is the first day of Early Bird pricing for the HUGE course at testingjavascript.com. I think you’re going to be blown away. Watch your email tomorrow morning for the link to get my latest and greatest Testing JS course, with a limited-time discount!)
The other way I’m celebrating is by sharing a few UI Testing Myths with you. Let’s get started!
Myth 1: “Tests always break when I make any changes to the code”
This is actually a truth… if the tests are written incorrectly. If your test is testing implementation details, then of course they’ll break when the implementation changes! But your user doesn’t care about the implementation details. In fact, they don’t even care whether you’re using React, Angular, or jQuery. So for the most part, your tests shouldn’t care about that either. 💯
Unfortunately, many tools out there encourage testing implementation details. Do that and you’ll often wind up rewriting tests. “Why am I even testing this!?” you’ll ask yourself, and I don’t blame you. That’s why on TestingJavaScript.com I show you how test the right way.
Myth 2: “I can’t test a “connected” redux component”
The conventional wisdom of testing components that use Redux is that you should test the component in isolation from Redux, and then test the Redux action creators and reducers separately.
But if you do this, your tests can’t give you any confidence that your components communicate properly with Redux.
Instead, you can actually test your connected component with your real Redux store. Do this, and you’ll get the confidence that your component is rendering properly, and that the Redux action creators and reducers are all working together in tandem. Just like they will in production. ✅
On TestingJavaScript.com, I show you how to test in this way. The same concepts apply for React Router 🔀 and other providers (like the Theme Provider from emotion 👩🎤), and the course will show how to apply this method to those, too!
Myth 3: “End-to-End tests are slow and brittle”
This, too, can be true if the tests are written incorrectly. A common mistake I see in E2E testing is doing the same things in every test—for instance, every test going through the whole registration and login flow before doing whatever is needed for the test. When you do stuff like this, you start seeing a lot of duplication, and that’s when you start creating things like “page objects” (which is a poor practice). 😐
On TestingJavaScript.com, I show you how you can get confidence that the registration and login flows are working, and then skip those for the rest of your tests so you can significantly speed up the tests and reduce the points of failure. When you write tests this way and use tools like cypress-testing-library, practices like page objects are totally unnecessary, and your tests are easier to maintain, more reliable, and run faster. You might even find yourself replacing Chrome with Cypress as your development workflow tool (which I show you how to do in the course as well!) 😱
Before I blow out the candles…
I can’t tell you how excited I am to share this course with you.
Make sure to tune in to tomorrow’s livestream starting at 11:30am ET. It’s going to be a good one! And check out yesterday’s Q&A, which was really awesome! Lots of great stuff in there (including a little preview into what the course topics are)!!
Today’s blog post is “Eliminate an entire category of bugs with a few simple tools”. 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.