Far too often teams or individuals stop writing tests for a number of reasons but here are the top three:

1. They take too long to run.
2. Very high learning curve – only a few teammates know how run them and even fewer know how to write them.
3. A lot of the codebase becomes non trivial, untestable state

You’ll hear a lot of that testing should be part of your culture, but when people talk about culture, what does that really mean? With tests, I think you can ask one simple question:

Do we treat test code like production code?

There are a lot of similarities you should draw from “production code”:

1. Does it run fast and efficient?
2. Is it written modularly for code reuse and extensibility?
3. Does it follow team coding style guidelines and code linters?

I’ve been on many teams that set very low standards on test quality to encourage the team to write more tests. I believe this has diminishing returns because tests can easily get copy and pasted, and can incrementally take longer and longer to run. This also has effects on the length and quality of code reviews that the test code is a part of.

Code is code, tests are code, so treat tests like production code

This will take effort and diligence. Luckily there are a lot of tools that assist in insight and analysis in your tests because after all, it’s just code but it ultimately comes down to your teams culture and values.

If your tests are not easy to run, or can run quickly, testing will soon be abandoned. If you and your team ask yourself this simple question from time to time, testing could very well be a part of your teams culture.