We spent a long time trying to convince people that automated tests are important. It's good to see that nowadays things changed and our discussions are more about the quality of our tests than if we are doing them or not.
However with experience we realize that not everything requires test and in some cases it's better to not have them at all. Madness? No, this is being pragmatic.
If you are reading this probably you already know about tests, but in case you are just starting and trying to see the value of it I'll list some benefits I see on writing tests:
- Backwards compatibility: Tests ensure that new features don't break old behaviors.
- Living documentation: Tests externalize the rules of your software.
- Up to date examples: Tests are your first client and one of the best ways to show how to use your code.
- Better design: Starting by writing tests guarantee your code is decoupled and have a good API.
- No time wasted on small issues: If you take small steps any typo or wrong implementation will be caught straight away. You don't need to loose time debugging code you just wrote
- Identifying smells: Bad decisions make your code difficult to test. You can use this difficulty as a thermometer to identify smells such as mixed responsibilities, too many dependencies and leaking abstractions.
With those benefits why would you prefer to not write tests? Well, it's all about trade offs.
Cases you might prefer not to write tests
1. When spiking a solution or experimenting new technology
Spiking is a good way to get familiarized with a new technology or finding answers for assumptions.Here you'll want to go dirty, hack and slash, copy and paste and make it work. Starting by testing will only delay your discovery process. You would be fighting test frameworks and loosing focus from what you want to validate.
2. When it's another person's code
It is a good strategy to isolate your code from third-party code. Having extra layers on top of libraries may feel overkill, but they pay off making changes, updates and even replacing dependencies easier.
Writing unit tests for this layer requires many stubs, mocks or fake implementations, which are difficult to maintain and to keep in sync. There is still the option of integration or E2E tests, however they are costly and in some cases flaky.
3. When it is legacy code
You should never test something that you don't understand. A test based on assumptions may cause more harm than good.
Testing legacy code is painful, difficult and not efficient. The best strategy is isolating the code and forgetting about it.
I know! It annoys you knowing there is that dark place in your code base. Every new developer will try to refactor it failing miserably or creating more legacy code and bugs in the process. Some people will even suggest to rewrite the whole application, but they will fail as well. Just keep in mind that if it doesn't affect your performance and your ability to change, it is better to let it be.
Creating tests for legacy code only creates a false feeling of safety. People will think it's ok to refactor it because it is covered by tests. Instead of putting a lipstick in the legacy pig it is better to write a big sign saying "Abandon hope all ye who enter here".
4. When it doesn't make sense to do so
Ok, You caught me. All the items before are all about this one. In summary, it is ok to not write tests when writing tests doesn't make sense.
It is not about coverage, but the quality of the tests you have. By quality I mean tests should be easy to maintain and easy to change. They should be consistent and ensure that your code is working fine. If you can't ensure your tests quality, maybe you should try a different approach.
Having said that, tests are an important tool. In most cases not being able to write them properly could mean that something else is wrong and requires your attention.
The decision of not writing tests shouldn't be a stigma as long it is conscious and supported by good arguments.
That's all for now. I appreciate feedback. If you have something to add, a different point of view, comments or suggestions leave them bellow. Thanks!
Photo credit: Internet Archive Book Images on Visualhunt