Well not exactly... Along with co-author Doug Rosenberg we've recently signed up with Apress to write a book about automated testing (i.e., unit testing, acceptance testing, new-kid-on-the-block behavioural testing, and requirements testing).
But... this won't be your everyday "toe the party line" automated testing volume that regurgitates the TDD doctrine. Instead, we're making the point that TDD is, to put it mildly, ass-backwards. Tests shouldn't be the sole design driver; instead the design can be used to identify the key areas of the code to cover with tests. In other words the design should drive the unit tests, just as requirements drive the customer acceptance tests.
We've found that, while it has much in its favour, TDD represents too much work for what you get out of it. For example, we definitely don't recommend that you go all-out for 100% test/code coverage, because you'll never achieve it in the time available... so what's the measure of success? How do you know when you've written enough tests and it's time to stop? Instead, we believe you should "test smarter, not harder" - in other words, identify the key areas of the code that will benefit the most from tests.There's a chapter on Design Driven Testing in our previous book, Use Case Driven Object Modeling with UML: Theory and Practice. However, in this new book we'll be exploring in much more detail the ideas and the practicality of automated testing, using a real-world, non-trivial project ("Mapplet 2.0") being developed at ESRI for a travel website. This project will use a Flex front-end hooked up to Java server code, which in turn connects to a hotel search XML database and ESRI's ArcGIS Server. So we'll be exploring how to go about unit testing an enterprise application with a mix of languages and technologies (just like the majority of real-life projects out there).
To top it all, Sparx Systems has developed an ICONIX Process add-in for their UML modeling tool, Enterprise Architect (EA), which automates many of the steps that we'll cover in the book. You don't have to use EA to use Design Driven Testing, but after seeing what's possible with the emerging tools support for the process, we believe you'll want to!
Stay tuned, I'll post more about the ideas behind Design Driven Testing over the next few days.