Test what should happen instead of how
A common problem I see is when a test tries to verify expected results by checking internal steps along the way. The test is checking how something is done. This type of test is fragile and often needs frequent updates and changes.
A better approach is to test what happens as a final result. Because then the internal steps can change and adapt as needed. The test remains valid the entire time without further maintenance.
If you find yourself going through your tests and frequently updating them, so the tests pass again, then your tests might be testing how something is done instead of what is done.
For example, in Chapter 10, The TDD Process in Depth, there’s a section called When is testing too much? that explains the idea of what to test in greater detail.
The general idea is this. Let’s say you have a function that adds a filter to a collection. If you write a test that’s focused on how the code works, then...
