Listening to your tests
Sometimes we find it difficult to write a test for some functionality we want to add to our code. In our experience, this usually means that our design can be improved — perhaps the class is too tightly coupled to its environment or does not have clear responsibilities. When this happens, we first check whether it’s an opportunity to improve our code, before working around the design by making the test more complicated or using more sophisticated tools. We’ve found that the qualities that make an object easy to test also make our code responsive to change.
Steve Freeman & Nat Pryce — Growing Object-Oriented Software Guided by Tests
Listening to your tests is one of the key takeaways I had from the book Growing Object-Oriented Software Guided by Tests (GOOS) book. Watch out tests for:
- Too many dependencies
- Too much setup
- Too many assertions
Follow Arrange, Act, Assert while writing tests. Group every test separated by blank lines as follows:
- Arrange all necessary inputs.
- Act on the object or method under test.
- Assert the expected results.
The Arrange, Act, Assert model makes the smells explicit when each section grows. For, e.g., if you need to write ten lines of setup (Arrange) code for a single test method (Act), it will be apparent. The same if there are too many assertions.
And practising listening to your tests elevates the team achieve Test Driven Design.
