Test Driven: Practical TDD and Acceptance TDD for Java Developers

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.

This is a fair enough book to start learning about TDD.

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.

If you are interesting in Java TDD with Junit this is your book. Cover different kinds of test depending what are you testing (Dao, logic, threads, etc). Also it has a good chapter of 'business test' and gives you a basic idea of other great tools like Fit.But if you are more interested in 'business test' probably the book Fit for Developing Software: Framework for Integrated Tests (Rick Mugridge and Ward Cunningham) it's much better option.

This book gives a good overview of TDD and it does cover a fair amount of ground. However, the treatment is superficial on some topics making it less useful for someone experienced with TDD. This book also discusses challenges in adoption of TDD across a team or an organization and offers some solutions for the same in the very last chapter. Novices to TDD will benefit the most from this work while for the rest the value addition may be marginal.

This book is very complete. It talks about basic concepts and also it treats many of the common problems related to TDD and acceptance TDD, so it is perfect for beginners in TDD and for intermediate level also.

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.

TDD and unit testing is something that my company is moving toward. This book helped me learn it quickly and it was also fun. The exercises are funny and they do well in proving the methodologies. Recommended.

O livro chegou bem antes do prazo que estava descrito (ainda bem haha) e muito bem embalado, qualidade incrível.

Contains a great deal of outside in design and development. One of my favourites and I've been acculating a wealth of TDD knowledge. I havent come across the details elsewhere.

Das Buch ist hervorragend geschrieben. Daß man den letzten Satz eines Kapiteln zum Titel des Folgekapitels macht, kannte ich noch nicht; das gibt dem Buch eine starke Struktur. Allerdings sind nicht alle Kapitel für alle Leser gleichermaßen interessant.Fasziniert hat mich der Anhang. Hier habe ich auf nur einer Seite alles über die aktuelle EasyMock-Version erfahren, was ich wissen wollte und in der Original-Dokumentation nicht gefunden habe. Genauso ist es mit JUnit, das auf sehr wenigen Seiten so umfassend erklärt ist, wie es der Normal-Anwender braucht."Test Driven" ist eines der Highlights in meinem Fachbuch-Regal.

Ok