- Why Spatial?
- Developer District
In Part I of this post, I pointed out a problem with xUnit tests: it is difficult to obey Once and Only Once when the validation assertions are outside the method(s) being tested. The solution, as I mentioned in my preceding post about contract checks, is to move as many assertions as make sense into contract checks. This has many benefits, most of which address the principles Stef was looking for (and the frustrations she encountered in applying them to testing Spatial's 3D InterOp product) in her post:
This is why I got so excited when I read Stef’s post – the frustrations she expressed lined up with my thoughts about the benefits of including contract checks as part of a unit (or system) testing strategy.
Before I go, I want to make one thing clear: I am not saying that xUnit is the source of the problems I’ve discussed above; it’s simply a very useful tool that makes it easy to write and run automated tests. Nor am I saying that contract checks are a silver bullet that will remove all complexity from the test code so that the techniques in Meszaros’ book will be unnecessary. What I am saying is that contract checking is an essential part of any testing strategy, and that developers who don’t use a contract checking methodology run the risk of running into many of the anti-patterns that Meszaros points out (and addresses) throughout his book.