I don’t mean that you shouldn’t write unit tests. You definitely should.
But you shouldn’t feel bad deleting unit tests when you have some that are no longer relevant. This usually happens due to refactoring, but also happens due to requirements changes. In these cases, your first impulse should be to torch your tests.
If this feels wrong to you, then ask yourself why?
Usually, we hate getting rid of something because it has meaning to us. Things that have meaning to us usually have meaning because of the time we put into them.
So if you hate throwing away some tests, that might just be because you spent so much time writing them. And that’s the key here: if you spent a lot of time writing a test, something is probably wrong.
In the practice of TDD (writing your tests before you write your code) tests have to be cheap and easy to write. TDD is about feeling better. It’s about zen. It’s about flow and coding. Effective TDD reduces cognitive load, and makes coding more pleasant, and faster.
On the other hand, tests that take a long time to write probably took a long time to setup, to understand, and to get correct. In fact tests that take a long time to write may have a reasonable chance of being incorrect. They’re also probably very closely tied in with the code they test. These are all reasons that it takes a long time to write a test, and are all indications that your unit tests aren’t very effective.
For more about this, see my recent video on why you’re probably writing your unit tests wrong.
This often happens because the tests are written afterward, so they’re an afterthought. Whether the code is easy to test or not is coincidental.
So let me make a bold statement here: You get 60% of the value of unit tests when you write them, and only 40% by keeping them around.
This may sound crazy, but when you TDD, it’s crafting the test that helps craft the code and makes the coding easier. It’s the scaffolding that makes building simpler and faster. After the building is built, it can still guide and document and create safe refactoring, but you’ve gotten SO MUCH value out of the test just by writing it, and letting it guide the implementation of your code.
Tests should be easy to write, and easy to throw away. Tests that don’t meet these criteria become friction. Tests that do meet these criteria increase velocity.
If you’re interested in learning more about how to do Test Driven Development in Angular, come attend my one-day workshop on TDD in Angular at ng-conf 2021.
Ready to build the most reliable web applications possible? Join us for the Reliable Web Summit this August 26th-27th, 2021 to learn how! A summit conference on building reliable web applications, including the following three pillars:
- Scalable infrastructure and architecture
- Maintainable Code
- Automated Testing
