Test Driven: TDD and Acceptance TDD for Java Developers [Paperback]

Lasse Koskela (Author)

Book Description

Publication Date: October 19, 2007 | ISBN-10: 1932394850 | ISBN-13: 978-1932394856

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.

Purchase of the print book comes with an offer of a free PDF, ePub, and Kindle eBook from Manning. Also available is all code from the book.

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

Editorial Reviews

About the Author

Lasse Koskela is a methodology specialist at Reaktor Innovations. He started promoting Agile methods in Finland in 2002, ramped up the local Agile Seminars in 2005, and has coached dozens of teams around Europe in agile methods and development practices such as test driven development.

Product Details

• Paperback: 470 pages
• Publisher: Manning Publications (October 19, 2007)
• Language: English
• ISBN-10: 1932394850
• ISBN-13: 978-1932394856
• Product Dimensions: 7.4 x 1.3 x 9.1 inches
• Shipping Weight: 2.6 pounds (View shipping rates and policies)
• Average Customer Review: 3.9 out of 5 stars  See all reviews (17 customer reviews)
• Amazon Best Sellers Rank: #54,596 in Books (See Top 100 in Books)
  • #29 in Books > Computers & Technology > Programming > Software Design, Testing & Engineering > Testing
  • #69 in Books > Computers & Technology > Programming > Languages & Tools > Java
  • #93 in Books > Computers & Technology > Computer Science > Software Engineering

More About the Author

I'm a consultant and trainer working for a software consulting company in Finland. During my spare time, I tend bar at the JavaRanch (http://www.javaranch.com).

Most Helpful Customer Reviews

19 of 21 people found the following review helpful

5.0 out of 5 stars My new standard reference October 22, 2007

By Bas Vodde

Format:Paperback

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! Read more ›

19 of 22 people found the following review helpful

5.0 out of 5 stars may be -the- book on TDD in Java November 2, 2007

By J.J. Langr

Format:Paperback|Amazon Verified Purchase

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.

9 of 9 people found the following review helpful

5.0 out of 5 stars test first or last - tools and techniques for testing well January 26, 2008

By Jeanne Boyarsky

Format:Paperback

"Test Driven" is geared toward Java developers interested in writing better JUnit tests. Despite the title, it is useful whether you want to write test first or test last.

The first part of the book covers the softer aspects of testing such as how to decide what tests to write first and spikes. The rest of the book covers writing tests for common Java components including servlets, data access code and Swing. Examples were for things that we frequently want to test. They included "hard" things such as testing times and threaded code.

I particularly liked the sections on design and testing patterns. There was good coverage of different JUnit extension libraries with examples including dbunit, jmock, easymock, jemmy and abbot. There was also a full chapter on FIT.

I got a sense of "in the trenches" realism from the book. Tradeoffs of techniques were clearing mentioned. The chapter on adopting TDD shows the experience of someone who has done it many times. The section on how to fight resistance really spoke to me.

This is the first book I have read using JUnit 4, which was useful for reading well written tests. While there is an appendix "tutorial" on JUnit 3.8 and 4.0 (two page annotated classes), you really should feel comfortable with one version of JUnit before reading this book. While a few sections pertained to specific technologies, such as Spring, the concepts apply to everyone. I highly recommend this book.

11 of 12 people found the following review helpful

5.0 out of 5 stars TDD and ATDD: a very well-written primer October 7, 2008

By D. Heinecke

Format:Paperback

For the last five years, I have worked for companies that espouse "agile" technologies and development practices. At my last job, the company contracted with ObjectMentor to come in and provide direct training and mentoring as we transitioned our old waterfall process into a shiny new eXtreme Programming (XP) one. We were even so fortunate to have some one-on-one time with Ron Jefferies, Michael Feathers, and Robert Martin to further help up along the path to XP enlightenment. At the time, I was a software architect and largely skeptical of many of the XP practices. Practices like short iterations, collective code ownership, user testing and a planning game were an easy sell to us; the practice of test-first development was not. In fact, in the controversy over whether design and code should be written "test-first" or not, I always sided with folks who felt that architecture should be worked out first, followed by coding it up and then testing. Even though I understood the importance of writing tests to ensure the quality of my code, I still clung to my old waterfall style for actually driving and writing those tests.
Fast forward a number of years to the present day and even though our development practices are very agile, test-first is still not one of those practices. As a champion of unit testing on my team, I happened to come across the book "Test Driven" by Lasse Koskela at book store one day. Thinking that this was just another one of those post-modern XP books (You know the ones that take one of the original XP practices, re-brand it with a new name and then claim to have invented something new?) with a slightly different take on test-first development, I almost didn't give it a second glance.... Since I had time to kill, I decided to thumb through it to see if I could confirm my suspicions. After the first few pages I found that I wasn't skimming the book at all; I was actually reading it. My initial skepticism gave way to understanding. When my legs started aching from standing for so long, I retired to a comfortable chair to continue. I was impressed enough that I ended up purchasing the book that same day. So what did I discover and was it enough to change my mind about test-first development? Read on for the answer!
In chapter one of the book, Lasse starts out by dividing the topic of Test Driven Development (TDD) into two different, but related subtopics: Practical TDD and Acceptance TDD. Practical TDD is more or less re-branded test-first development (TFD) from the early days of XP, and the Lasse spends some time going over the advantages of developing software using a TDD approach. Many of these advantages have been hammered on before and to any agilist should consider them standard fare: ensuring high code quality, ensuring that the code isn't over-designed, ensuring that defects are caught early, etc. Into this mix of vintage advantages, he then tosses the concept of Acceptance TDD (ATDD). In contrast to regular TDD (RDDT?) which is primarily aimed at the development of classes and components, ATDD is aimed at the development of systems and subsystems. In short, ATDD is about writing acceptance tests first that the system as a whole must pass in order to be acceptable to the customer, while RTDD is about the development of the individual classes and components that comprise the subsystems. Lasse asserts that being able to do both forms of TDD will ensure high quality code that the customer actually wants. Having been burned countless times at customer acceptance time, ATDD was a topic that interested me immediately. Unfortunately, we have to wait until the later chapters in the book before we get into the details of ATDD. I felt that Lasse makes an excellent case in chapter one for TDD, and his overview of both RTDD and ATDD left me very interested to hear more. The chapter ends on a rough overview of some of the existing tools for doing automated testing and builds and for doing code coverage. Depending on your existing understanding of agile methodologies, you might just consider skimming this chapter.

In chapter two and three, Lasse jumps off into how to begin to do TDD. In order to introduce the reader to the nuts and bolts of how to do TDD, Lasse walks the reader through a contrived development story and the development of a module to fulfill the requirements. Unfortunately, this chapter was not my favorite one but not because it wasn't well-written, or wasn't very informative: quite the contrary is true! My problem with this chapter was that the example was too simple: developing a simple template engine. This has been one of my biggest gripes about TFD for years: all the books and articles that I've ever read about doing TFD just present very simple, almost trivial, examples of how to write code in a test-first manner. In this regard, Lasse goes through the motions of writing the failing test, coding the module, writing the next failing test, etc. until we have a module that passes the tests and meets the requirements. I understand that this is probably the first time that the reader might have seen the entire process laid out end-to-end, but I was disappointed that the complexity of the example wasn't a little more in line with what a developer is likely to see in their daily queue. In chapter three we see how refactoring plays into the process of TDD and Lasse demonstrates how to modify code and tests in the template engine. Chapter three seemed a little too short to me, and seeing as how it was a continuation of the template engine example, most of the information could have been folded into chapter two.

Chapter four steps away from the examples of the previous chapters and focuses on the strategies and patterns for testing. He presents testing patterns, guidelines, and concepts in a very general sense. As a true believer in unit testing already, I found most of this chapter to be rehashing the case and the techniques for unit testing. His section on testing patterns and mock objects was fairly short, but as a first look at the topic, it might be adequate. If you find chapter four to be interesting, you should definitely check out "XUnit Test Patterns: Refactoring Test Code" by Gerard Meszaros, which is considered to be the definitive work on the subject. Lasse does an admiral job of adding his own mini examples, like why one should avoid static singletons in production code, why isolating dependencies make code easier to test, and so on. Again, most of this chapter should be familiar if you are already an agile tester, but it is a very good introduction to the subject.

In the second part of the book, Lasse addresses how unit testing should be applied to specific technologies. In chapter five, the topic is how to apply TDD to web components. This section really raised my interest level because testing web applications has always been a pain for me. Even though this section only weighs in at about 40 pages or so, the information presented is pretty dense. I did feel that the page or two that he spends covering how MVC works was wasteful: if you aren't unit testing web applications then why wouldn't you just skip this chapter? If you are unit testing web applications then you should already have a good notion of how MVC works. Not that this should be considered a serious criticism, it just seemed a little out of place. The rest of chapter contained very useful information to me: how to get started unit testing controllers and views. He also covers testing with the Spring controllers, which is very useful if you have a fortune to be using Spring MVC or Webflow. In the last part of the chapter, Lasse goes over how to create the view in a TFD manner, and he goes over how to use tools like JspTest to do so. He also covers how to do TFD in other web frameworks, like Wicket and Velocity. The section for these last two was very short and I wish that Lasse could have included more examples.

Chapter six deals with testing the database. Lasse makes the compelling case of why it is important to test your database layer and gives some examples of working with straight JDBC to accomplish this task. He quickly moves to higher order abstractions, like DAOs and Hibernate and why these are unit test Nirvana. Since I have the good fortune to be working with Hibernate already, there wasn't anything particularly new or earth-shattering here, but his examples of how to set up and run an in-memory database for testing were solid. Tacked on to the end of the chapter was a page or two about how to test file-system access. Lasse provides some good advice if you are unit testing file accesses, but I found the page or two that he dedicated to the subject insufficient to do the topic serious justice. I would also have liked to see some example code and this is an area that I felt should expanded in the 2nd edition.

Chapter seven deals with unit testing time-based components and threads. Using the same approach of abstraction that he uses elsewhere, Lasse explains how to test logging systems where time-stamp and time formatting are used. He also covers how to test multi-threaded code in the second half of the chapter. I felt that this was a very important chapter since multi-threaded and multi-core is where the industry is headed, and I felt that Lasse's introduction to how to test threaded code was a solid introduction to the subject. Like most things so far, I did feel that it was laking in depth somewhat and I would have been happier with some more examples around the Java 1.5 concurrency API.

Chapter eight addresses how to unit test Swing UI components. If you are doing Swing development, then this chapter is a must-read. After the obligatory discussion about why you should unit test your Swing components, Lasse then gives some very good examples of how to actually do it. From unit testing View components, to working with standard widgets, to drawing custom graphics, there is something here for every Swing developer. If I found his examples in other sections of the book a little sparse, it was definitely not the case in this chapter and I found myself really getting excited about being able to test components that I had previously believed were untestable.

Part three of the book was worth the purchase price of the book for me. As I mentioned earlier, this is the section where he describes Acceptance TDD, the process involved and some of the tools that can make the process easier. In order to cover the subject, the book goes back over some familiar ground: the user story, and shows how ATDD fits into the process of writing the story with testability in mind. The anecdotal stories and methodologies described in this chapter were enough to get me thinking about how I could integrate ATDD into our development process. Chapter twelve of the book addresses exactly this topic and I was able to compile a list of ideas and ways that I could get ATDD to work for me.

So was the book worth it? Absolutely. In addition to reinforcing my already strong beliefs in the power and necessity for unit testing, it also gave me some very good starting points for being able to write the hard tests (web and Swing UI components). In addition, the chapters on ATDD were surely an eye-opener into how productive me and my team could be. Read more ›