Probably most of us seen or came to a project where there was no tests or there was very few of them. On the other hand there is another big fraction of software (quality) engineers struggling with test suites that last for hours. In both situations the main question we should ask is “how many tests should we really have?”.
This is not that easy question to answer. First of all we need to realize why exactly do we need automated tests… Basically there are three main reason to automate testing effort:
- The project we are working on is living.
This is very important one. There is no need to invest time in creating automated tests on many different levels if the application is not under active development. If you want to just make it and deploy once – simply test everything manually and save your time.
- Ensuring quality.
We automate tests to avoid regressions. When bugs are reported from production after every release that is the sign you probably need more tests to meet quality expectations.
- Encouraging changes.
It’s very important, but often forgotten that automated tests serves developers in they everyday work and should make them feel comfortable with introducing changes. If any developer avoid making changes in some area it should be an incentive to cover this part with more tests as there probably resides main complexity or legacy code.
Summarizing, if you and your team are not worried about providing changes in the application and it is very exceptional situation that a bug is reported to your app you probably have enough tests for your need and you may even consider reducing test suite in order to achieve better deployment pipeline time. But if you work in a project where either you avoid touching some areas in the code base or fixing reported bugs from production is your reality consider increasing test coverage and make your life easier.