Rating:  - Very harmful approach
When I purchased the book "Test Driven" by Lasse Koskela I hoped to see suggestions, patterns, and tools for continuous testing during the development cycle. It is not a secret for an experienced developer that postponing the testing phase until the design and implementation are complete is very dangerous. Every real world developer is well aware that implementation quite often reveals design shortcomings, while testing does the same for implementation, and less frequently for design deficiencies. Refactoring provides the flexibility to make incremental improvements during the implementation and testing phases.
What I found instead is a manifest of software development madness. The book proudly presents in pictorial form (as if words weren't sufficient enough) on page 15 a reverse development cycle: test - implement - design. And naturally, since there is no design forethought, testing is followed by endless refactoring to improve the design and implementation in order to achieve better and better results. Which, in my opinion, doesn't equate to good or great; it still equates in best case to mediocre. Why?
The power of software design (OO especially) is the ability to establish inherent relationships and commonalities between seemingly unrelated domain entities and model systems in our mind (and modeling tools that exist in abundance) before they materialize in a final product. We design frameworks in order to use them over and over again. Well designed and reusable components should have minimal yet complete interfaces to be successfully utilized in more than a single application. This doesn't come from the test and try approach; it is the result of a significant design effort. There are many other things that I could write about software design work and positive aspects of this activity, but this is a book review, so let's switch back to the topic.
I am very perplexed with a proposal to substitute use cases or user stories with test cases (page 46). In short these are different activities usually performed by different people with different sets of qualifications.
The suggestion to "choose composition over inheritance" (page 119) is very strange. Inheritance reflects a different relationship which could and should be exploited in design and implementation. I found ridiculous the argument to use this advice to simplify testability (not even improve). Page 121 suggests avoiding Singleton patterns claiming that "object instantiation is dirt cheap with modern virtual machines" as if static and Singleton are used to make code more efficient.
And I could go on and on.
I don't disagree with the desire to be agile; it keeps you grounded in reality. It is hard, or close to impossible to achieve first-class results without iterations. That is why the waterfall approach fails so miserably. Testing - unit, functional, system, performance etc. - is critically important during all stages of development. Test plans should be created in parallel with the design and implementation efforts. As regression tests are software product "sanity checkers", unit tests keep developers confident as they make progress.
Why would one think that the right approach is turning the development process on its head? I think that it is extremely harmful for young software developers, who would bypass the necessary steps (and pains) of a systematic routine of building good software.
To tell the truth, as entertaining as it was to discover more and more intricate details of TDD, I stopped somewhere on page 100 and browsed through the rest without going into details.
On a positive note, "Test Driven" has a reasonable amount of good references to existing tools and technologies. The book stresses the importance of testing, including acceptance, and gives interesting insights into various techniques. Code examples are well written. The refactoring suggestions are very sensible as well. Apparently, the author has first hand experience with the methodologies and tools he describes.
My major disagreement is with the fundamental principles in this book, not in practical terms and advice. 1 star rating reflects my very negative attitude towards approach. A lot of recommendations are very useful.
I came up with this metaphor for the book: Lasse Koskela is building a house for a young couple. They are vivid bikers. So, Lasse builds a bedroom and a bike room. Tests passed. A few years later the couple has a child and the bike room has to be remodeled to be a baby's room (not the best room for a child) or he adds a room by eliminating one of the garage spaces. Tests still pass - everybody is alive. Then a second child arrives, and Lasse has to add yet another room, in the process having to relay new electrical and plumbing lines. Tests still pass. The result is an ugly, poorly designed house that the original family leaves and nobody else wants to move into.
Rating:  - Buy this book NOW!!!
As an intermediate java developer, I like a book which explains a little theory and backs it up with good examples (which eventually can be expanded into my work in commercial java development). This book fits the bill precisely and is one of the best and most useful technical books that I have read so far. The writing is interesting and the example code works. I especially liked the chapter on data access testing and the ones covering web apps and EJB testing were interesting as well.
Overall, the author makes an excellent argument for test-driven development and covers the current java technologies (Spring, Hibernate, EJB 2 and 3, etc.) to date.
Buy this book and you will not go wrong.
Rating: - may be -the- book on TDD in Java
I've just begun digging into Lasse Koskela's book, Test Driven, but it's already clear that this is the book I will recommend to existing Java programmers for a thorough coverage of TDD. (I'm pointing new Java programmers somewhere else, however. :-))
The text is very well written and engaging. The introductory material, getting developers up to speed on what TDD is and isn't, and how to do it well, is very patient yet not so slow that it's tedious.
The book is well-rounded, and contains information that you're not going to find in the other books on TDD. For example, it includes a good introductory coverage to acceptance testing using FIT/FitNesse. It also includes some recommendations on multithreaded testing, and some practical discussion about the distinctions between unit and integration testing, and what's entailed.
I think Koskela did a good job at surveying the current Java landscape and providing recommendations around the predominant tools/environments. I hope he's able to update the book in a couple years!
Overall, the book has many useful tips throughout, and wraps up with a thorough discussion of what it will take to adopt TDD in an organization. So far it's one of the more enjoyable and useful tech books I've read this year.
Rating: - My new standard reference
Lasse's new book, "Test-driven" is now my standard reference for people who want to know more about TDD. Why? Simply because his new book covers it broad, well and in detail. It's the first book I know which also covers the "Acceptance TDD" part and it was about time!
The book consists of three parts. They are: "TDD Primer", "Specific technologies" and "Acceptance TDD".
The first part contains an overview/big picture on what TDD is and especially how the traditional TDD and A-TDD fit together. The first chapter is probably the best overview explanation I know of TDD, A-TDD and the effect on the quality of the code, the effect of refactoring and how to develop software incrementally in small steps (and why you would actually want to do that). The second chapter then dives into the "how do you do this" question and goes over one example to show concretely, in code, how to do TDD. The third chapter focuses on the refactoring step in the traditional TDD cycle. Without refactoring your design will be a mess, though this step is often hard for new TDDers. The last chapter of part 1 then covers concepts and patterns. Concepts are like the different test strategies for test-driving your code. Other example that's covered here is the problems of legacy code.
The second part of the book tries to give concrete answers to common problems. How to I test-drive x! It starts with web components and moves from there in the database area (or data access code). One chapter about test-driving time related issues and then also the extremely hard problem of test-driving multi-threaded code. This part ends with test-driving Java Swing GUI code (using Jemmy)
The third part of the book is the A-TDD part. The first chapter in this part gives an overview of what is meant by Acceptance-TDD. The next chapter talks about FIT, which currently is the most widely used testing framework for A-TDD. The third chapter covers different strategies. Should you test via the interface? Why not, why yes? This chapter answers questions like that. The last chapter helps with adopting TDD. TDD is a really really hard practice to get used to and you'll need lots of approaches to help people get used to TDD. The last chapter covers these.
The authors writing style is very easy to read. The book keeps you reading, even if you already know a lot about TDD :) Lasse has a lot to tell. This is probably the most thorough TDD reference I know and I'll use it as my main reference book on TDD. Thanks for writing it. Recommended!
|
