Let's start the discussion about testing along the lines of the test pyramid (the test pyramid can be traced back to Mike Cohn's book "Succeeding with Agile" from 2009) in the following figure, which is a metaphor that helps us to decide how many tests and of which type we should aim for:
Figure 7.1: According to the test pyramid, we should create many cheap tests and fewer expensive ones
The basic statement is that we should have high coverage of fine-grained tests that are cheap to build, easy to maintain, fast-running, and stable. These are unit tests verifying that a single "unit" (usually a class) works as expected.
Once tests combine multiple units and cross-unit boundaries, architectural boundaries, or even system boundaries, they tend to become more expensive to build, slower to run, and more brittle (failing due to some configuration error instead of a functional error). The pyramid tells us that the more expensive those...