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 tests 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:

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 with 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 losing 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 codebase. 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 rewriting 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 properly. If you can't ensure the quality of your tests, 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, which may require 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. If you have something to add, a different point of view, comments or suggestions, leave them below. Thanks!

Photo credit: Internet Archive Book Images on Visualhunt