Types of tests

There are different kinds of tests, each with different costs and value. 100% test coverage is not the goal. Correct and maintainable software is, so we should strive to add the most valuable tests first.

Consider the test pyramid as a way to think about bringing balance to the force that is your tests.

As a general rule, prioritize coverage on business rules and features that introduce risk or potential user consequences or annoyance before lower level or simpler components.

Unit tests

Write lots! You should strive to have good unit test coverage of business rules. These are the cheapest to build and the fastest to run. Focus on these first. As much as possible, try to ensure your tests are testing what your APIs do (inputs/outputs), not how they work. Tests that are coupled to implementation details can make refactoring expensive.

Integration tests

Write some! Integration tests can be more expensive to build and maintain than unit test, but are great for ensuring your code works well together. These can help surface issues with configuration or scenarios where behaviour works slightly differently in-memory vs. connecting to a data source.

UI tests

Maybe write a few! Automated UI tests are more costly to set up and more difficult initially when there is lots of change happening quickly in an application. They start to pay off when the app is a bit more stable and a UI test automation suite can help you identify regressions and help run end to end scenarios from the perspective of a user.

Performance tests

Consider running load tests during your project. Some issues are hard to identify when looking at code and will only surface with concurrent usage (thread or connection pool issues for example).