This presentation
Sustainable Test-Driven Development discuss and show how to make :
- unit test code easier to read
- failing test messages easier to understand
- unit test code more resilient to changes in application implementation details
Writing your own DSL to create tests data builders helps for point (1): indeed it make test setup code more short and easier to read. Also the DSL separate the definition of what test data is created (the setup code of the tests do this) from the implementation details on how is created (the DSL implementation do this).
Writing your own test data builder DSL helps also for point (3): the details on how test data is created are defined in only one place (in the DSL implementation code) so when the application evolve and implementation details change it is needed to change test code in only one place in the DSL implementation and all tests will continue to work properly as before.
Implement your matcher objects to specify test condition in a concise and precise way that is easier to understand and that display a clear message when the test fail. This help for point (1) and (2).
- A framework for Test Data Builders is described in the book Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce. The porting to the .NET version in available here:
make-it-easy
- A framework for objects matcher ported to .NET is available here:
NHamcrest
No tool nor technique can survive inadequately trained developers
This is the advice I reserve to myself. That's why I'm watching again with attention the presentation and I am experimenting with my DSL test data builders and object matcher driven by design principles in order to be able to use the tools properly (instead of been misdirected by some tool feature)