Why bother with tests anyway?
Unit tests encourages developers to write modular and reusable components.
If those components are isolated enough, it should be easier to validate and maintain.
However, dev teams need other types of tests in addition, for example:
- functional tests
- e2e (end-to-end) tests
Just because a single component works does not mean the entire feature is ready to go. Dependence on unit tests alone is risky.
Signs that your units tests should be improved
Let's review some examples:
- the tests are not automated (e.g., manual run, no build, no CI/CD)
- the tests are difficult to read (e.g., no recognizable patterns like AAA, nonexistent or bad naming convention, too much asserts per test, etc)
- there's a tight coupling between 2 or several tests (e.g., chained tests)
- the tests focus on the implementation instead of the behavior (e.g., it duplicates the implementation logic)
- there are too many tests, to the point that modifying small blocks of code breaks dozens of tests
- some tests are redundant, which could impact the build time and the CI/CD
- the tests never fail, regardless of your modifications in the code
- you read code coverage at face value: while it IS important, it's not a quality indicator
So... developers are doomed?
Don't give up. Just because tests can be tricky doesn't mean it's a losing game.
It's a craft.
Besides, there are practical solutions to improve the situation:
- code reviews: let [more experienced] teammates read your tests, not just your code
- you may remove redundant tests and improve existing tests when refactoring
- consider adding mutation tests
Top comments (0)