Reviewed: September 2013

In a recent Agile Testing Survey [2], 37% say that adopting test-driven development (TDD) is the most difficult challenge. As Martin Fowler explains, there are two main benefits of writing a test (in code) before the functional code: you get the repeatable tests as well as the code, and your functional code is easier to call because you think about how to call it as you write each test. The main challenge is to maintain the discipline of refactoring the code, to improve the design, while continuing to pass the tests [1].

The book starts by walking through an analogy with object oriented applications. Chapter 2 ends with the first specific recommendation: build and modify each database instance (development, test, production) to the required state, by applying the same version-numbered scripts in strict sequence. So far, not so bad. The test-first examples are all for SQL Server, and the very first one tests whether the database exists. I prefer not to get in at the deep end, and don’t have SQL Server, so I copied the scripts (SQL) out of the NUnit and C# code, and ran them directly in database sessions (Oracle, MySQL). One of the early examples is an elaborate test, using a C# exception, for adding a unique constraint. Here a simpler script (inserting two identical emails, and then failing on adding the database constraint) could be used to the same end, and could also show how the test-first technique can be adapted for databases.

This tendency to complexity is distracting, if not infuriating. In a worked example for a cross-reference of street intersections, a simple problem description is followed by two full pages of ‘big design up front’ as a deliberate demonstration of how not to do it. When you do get to the test scripts, they insert some data and test for a connection depth of 3, whatever that means. A simple query on a view of street addresses, listing where other streets intersect, would be more effective.

You can find an example of refactoring in the chapter ‘Safely Changing Design’, which is about checking that data is preserved during a change. That’s good advice, but the discipline of refactoring is not treated explicitly until chapter 11. That chapter begins ‘This book isn’t directly about refactoring’, revealing an outlook that reflects the challenge identified by Martin Fowler.

You won’t find any advice on developing business logic in the database (“you should never do this”, page 97), or on developing for ‘NoSQL’ databases (despite chapters 14 ‘Variations’ and 15 ‘Other Applications’). This book is not for me, and I can’t recommend it.

Downloadable code is available, all for Microsoft products as far as I could see: similar open source tools are described at datacentricity.net/tsqlt/

References
[1] Martin Fowler online martinfowler.com/ bliki/TestDrivenDevelopment.html
[2] Agile Testing Survey November 2012, Ambysoft www.ambysoft.com/surveys/ agileTesting201211.html