Signs that your test scope is too small:
- You need to adapt tests for refactorings. In general if you touch your tests, you are not refactoring. You are redesigning.
- You seem to be testing implementation / code instead of functionality / features.
- The unit under test is used by only one other class - which also belongs to your team. Basically it’s just a separated helper class.�The detail that you have this class is an implementation detail. Do not expose it to your tests.
Signs that your test scope is too big:
- You have trouble identifying/testing all test cases due to big scope.
- Your unit test takes more than [1-100]ms to execute.�Not sure on the exact number. Most unit tests should be <= 1ms. Some may have some dozen ms. However the goal is to have ALL (relevant) unit tests executed within 1 second.
- The unit under test spans multiple teams.
- When the test fails, it’s complex to figure out where exactly the errors is
Signs that your test scope is just right:
- Your smallest units under tests are the most detailed element in architecture / detailed design.
- Your tests use the same API as someone else is using to interact with your unit under test.
- Your unit is used or intended to be used by many others, especially from other teams.
Surprisingly “unit” is the most vague term in the entire test pyramid. Some seem to think that a unit is something well defined like a class. It is not. Testing every function or every class is the worst thing you can do.