Some unit, integration, and system tests are unnecessary or problematic.
For each automated test you write, ask yourself:
- Does this test offer any additional test coverage that is not already addressed by some other existing test?
- Which defect(s) do I expect this test to find or prevent?
- When this test fails, would I be able to easily determine what went wrong based on the test execution report?
- Can I reduce the scope of this test so that it integrates fewer components during its execution?
- Am I testing a private method directly? If so, can I modify my test or refactor my code and test through a public method instead?
Each test should exist for a good reason, and not merely to tick a box in a checklist. The effectiveness of your testing is dictated primarily by the quality of the tests you have. The number of tests that you do or do not have matters much less than you think.