- ISBN13: 9781932394856
- Condition: NEW
- Notes: Brand New from Publisher. No Remainder Mark.
Product Description
In test driven development, you first write an executable test of what your application code must do. Only then do you write the code itself and, with the test spurring you on, you improve your design. In acceptance test driven development (ATDD), you use the same technique to implement product features, benefiting from iterative development, rapid feedback cycles, and better-defined requirements. TDD and its supporting tools and techniques lead to better software faster.
Test Driven brings under one cover practical TDD techniques distilled from several years of community experience. With examples in Java and the Java EE environment, it explores both the techniques and the mindset of TDD and ATDD. It uses carefully chosen examples to illustrate TDD tools and design patterns, not in the abstract but concretely in the context of the technologies you face at work. It is accessible to TDD beginners, and it offers effective and less well known techniques to older TDD hands.
What’s Inside
Learn hands-on to test drive Java code How to avoid common TDD adoption pitfalls Acceptance test driven development and the Fit framework How to test Java EE components-Servlets, JSPs, and Spring Controllers Tough issues like multithreaded programs and data access code
#1 by Ilya Volvovski on February 13, 2010 - 9:05 pm
Quote
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: 1 / 5
#2 by Jim L on February 13, 2010 - 9:58 pm
Quote
… instead of fellow authors looking to pump each other’s books up?
I read the book, wasn’t impressed, and popped it on the shelf to collect dust.
If you want to learn about TDD, read Beck’s book: it’s the standard everyone goes by. This book has some good points, but it’s certainly not worth the shekels.
Rating: 1 / 5
#3 by J. D. Litwiller on February 13, 2010 - 11:04 pm
Quote
As an experienced developer in an XP shop, I am always on the prowl for good books on TDD. Alas, this is not one of them.
The author uses a lot of exclamation points! And little puns! And a conversational tone that is both annoying and condescending.
In addition, he quotes so many other books that I felt as though I should be reading *those* books instead of his.
Much better material can be found for free at the various XP and Agile resources on the Web.
Rating: 1 / 5
#4 by John Wesley Watson on February 14, 2010 - 12:34 am
Quote
Very good introduction to TDD. I read this first, and then followed it the Beck’s TDD By Example, which was more in depth.
TDD is doubtless one of the most powerful software development tools I have come across in recent years.
Rating: 4 / 5
#5 by toverlier on February 14, 2010 - 2:33 am
Quote
This book is one of the best books I have ever read. It’s easy to understand and well-written. It dives deep into TDD without complicating things, and shows with good examples why you should do TDD.
Highly recommended.
Rating: 5 / 5