Customer Reviews

Design Driven Testing: Test Smarter, Not Harder

5 star:		(3)
4 star:		(3)
3 star:		(0)
2 star:		(0)
1 star:		(0)

 

 

'Design Driven Testing: Test Smarter, Not Harder' is the second book that I've read by authors Doug Rosenberg and Matt Stephens, the other being 'Use Case Driven
Object Modelling with UML Theory and Practice'. Once again I've been impressed, not only by the content but also, by the manner in which concepts are presented. I have a technical background and spend a considerable amount of time reading journals, blogs, articles and books and I especially enjoy it when the author screams out with passion for his/her subject, as in this case.

Before reading this book I'd not heard too much about DDT and even now it doesn't seem to be generating a huge amount of noise. I think this is maybe because a lot of people and organisations have spent vast amounts of time, money and hard effort investing in TDD.

I've been fortunate to have used TDD on many projects and it never surprises me the number of times when 'TDD' projects are not actually 'TDD'. From a high-level it seems really simple but then again simple things are not always what they seem.
By reading the accounts of Rosenberg and Stephens it's amazing how much one can learn not just about DDT but also TDD. It was also fascinating to learn that a lot of things I've done in the past have been very compatible with the DDT approach, such as robustness analysis and testing `hot-spots'.
I'm not sure if I'll be making the move to a pure DDT approach, but nonetheless it's shown flaws in past TDD projects that I've been part of (e.g. chasing code coverage, lack of design and not thinking deeply about acceptance testing).
The book is a good read and I appreciated the examples and simple concepts such as top 10's. I highly recommend the book even if you're not likely to use DDT because, like me, it's made me think long and hard about TDD and how to get the most out of it.

Summary:
In software development there is no shortage of methodologies. A seasoned software development team will be careful not to plunge headlong into a particular methodology without properly understanding its strengths and weaknesses. As the proverb says "A person seems right until someone comes forward and questions him." This book provides insight into challenges you may face with a bottom up approach (TDD in particular) and offers a top down approach (the reverse of TDD, or DDT).

Audience:
This book will prove useful to several audiences - managers, architects, analysts, developers and testers. Software development isn't about one role (for example testing) dominating the life cycle - instead it is an ongoing collaborative approach. This is where design and modeling can help to transfer the right requirements to classes and into code. The design drives test cases naturally.

Likes and Dislikes:
The conversational style of writing pulls the reader into the discussion around challenges with proper testing of a real application. If you already understand the benefits of software modeling, you will quickly appreciate how your knowledge can help with smarter software testing. The authors are not advocating an either/or approach between TDD and DDT. Both can coexist but TDD has some blind spots to be aware of. Those who use Enterprise Architect as their modeling tool will be pleased to find several useful screenshots and examples included.

Those who have read and benefited from previous books by the authors will find some of the earlier information repetitive. Thankfully the authors point readers to their other references and quickly move on.

Level of experience required:
Even though the focus of this book is on testing, the ideas run much deeper and complement other books on Domain Modeling by the authors. This is really a book that will help a software team prepare for testing in a well-rounded manner. All levels of experience should read and benefit from such a book.

Recommendation:
This book is a great reminder to take a step back and examine what you are trying to accomplish in a software project. Developing aimless test methods without knowing the bigger picture can potentially lead to wasted time - something no one can afford. Be smart, test the right things. Abstraction and iteration work so use them. I heartily recommend this book for those looking to test software projects using a proven, team oriented, common sense approach.

For those who couldn't believe that it was possible to have upfront analysis and design in an agile, test driven mindset (acceptance testing included), this book shows exactly how to do it, step by step.
Doug Rosenberg and Matt Stephens introduce us DDT, Design Driven Testing, a broader approach than TDD (that is presented at the beginning of the book to show the differences). I liked very much the Chapters about design-oriented testing, with controller and unit tests, and analysis-oriented testing, that presents customers (generally forgotten tests), business analysts and QA tests.
But the authors really deliver what they promise at the subtitle "Test Smarter, Not Harder" when they present the Controller tests, which cover more functions with fewer tests and when you use a tool that integrates the code and the design. A real example of a real application using a real tool makes things seem more, let me say, real.

I have been driven crazy in the past by over-engineered projects that end up costing more than they should simply because the methodology calls for it. The 'Test smarter, not harder' approach in this book is a breath of fresh air.

We build systems to a business-driven design, so it makes perfect sense to test software from the point of view of that design, not the point of view of the language.

The examples given in this book show a blow-by-blow account of the internal flaws in test-driven design. I am a fan of testing, but an elegant test with appropriate coverage will always be better than a thousand arbitrary tests which prove the internal consistency of a method or class.

Buy this book and change your thinking.

I'm very glad I came across this book. I'm new to the space of Test Driven Development(TDD) and was having a hard time wrapping my head around the concepts. It seemed to me that the goal of TDD was to unit test every function written by the application and seemed to be getting away from the purpose of the application itself. To me, it appeared as if there was little emphasis on the customers goals for the application and acceptance criteria. Just making sure all your code works does not necessarily mean the application has achieved the criteria set out by the client. The tests driving the design also didn't make much sense to me, because it doesn't really address the needs of the users for whom the application is intended and suggests a design geared to functionality and not usability.

Design Driven Testing(DDT) is a very neat philosophy that gives equal consideration to the technical folks developing the software and the client for whom it is intended.

Design Driven Testing by Matt Stephens and Doug Rosenberg begins appropriately by comparing and contrasting these two philosophies using a "real world" example. It clearly details where the philosophies diverge and is a great setup for the rest of book, which continues to indicate exactly why and how DDT is so much better. The style of writing is clear, concise and very easy to read. The authors illustrate their point of view by using real world coding examples. The simplicity of the examples themselves is a great advertisement for DDT.

As a consultant, acceptance testing is very important to me and the focus in the latter part of the book on Controller Testing is great. To me, this is where TDD fails and I was very glad to see an emphasis here on the higher level purpose of the application and not just making sure the code doesn't generate an exception.

Overall, this is a great read and a good starting place for anyone getting into Design Driven Testing or even Test Driven Design.

This is the second class I have asked Doug to teach for me. We are using the book in a development and maintenance environment. I purchased about a dozen copies for the class Doug was teaching. They really appreciated the book and class. I was thankful Doug took the time to customize the class to meet our needs. The feedback from my team is that the book and class are very helpful and will assist our development efforts.