UI Testing Myths
November 08, 2018
Some common myths around testing and what the reality is...
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. 💯
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. ✅
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). 😐