Test-Driven Development, TDD as it is commonly called, is an evolutionary software development technique that involves first writing a test case and then implementing only the code necessary to pass the test. TDD gives rapid feedback. Its usually a 3 step approach, write test, write the code, and finally refactor.

The book is written by Lasse Koskela , a methodology specialist at Reaktor Innovations in Finland, has coached dozens of teams in agile methods and practices such as test-driven development.

Here is a brief description of the book from Manning's web site:
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, 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.

And to know what's inside the book:

* Hands-on examples of how to test-drive Java code
* How to avoid common TDD adoption pitfalls
* ATDD development and the Fit framework
* How to test Java EE components Servlets, JSPs, and Spring Controllers
* How to handle tough issues like multithreaded programs and data-access code

If you would like to get more details about this book, here is the link: http://www.manning.com/koskela/

Lasse Koskela takes a few moments to sit down with Javalobby and talk about his experience of writing this exciting new book.

Q: Hi Lasse, could you tell us a bit about yourself, and where you work?
I'd be glad to do that, Meera. My journey in the software development industry began during the last IT bubble when I jumped ship from the online media business to work on the sexy web stuff. I first started programming simple database-driven web applications for a publishing company and soon joined a small new media company where I became the jack-of-all-trades for our two Java-based products. Back then I was spending way, way too much time in front of a computer but I was also learning a lot. Every day.

Around 2002 I started feeling a bit cramped with my little sandbox of the two Java-based products and decided to move on again. This time, I went for a big multinational consulting company, looking for opportunities to work on really big systems. Around the same time my interests started moving strongly from purely technical topics towards
the world of techniques, methods, and methodologies. Eventually I became the internal agile evangelist in a company that had experienced massive success with heavyweight processes.

Some three years later I was again looking for a change. I had basically failed in my attempt at turning the multinational consulting company's direction towards agile methods and decided to change my organization the other way. In the summer of 2005 I joined my current company, Reaktor Innovations, a small 80-man consulting powerhouse
based in Helsinki, Finland. We specialize in solving the most challenging problems our clients throw at us and we use agile methods all the way. We've recently started doing more and more coaching on agile methods and these days I spend most of my time doing just that--helping our clients' developers and product management get the most out of their time and investments.

And I'm loving it! I get to move back and forth between solving technical problems, solving organizational problems, training developers, being a developer, coaching team leads, and mentoring product managers. I'm truly lucky to be in this position.

Q: Why did you decide to write this book?
I decided to write this book because of envy. Let me explain. Back when I first started thinking about the book's contents, I realized that I was going to write the book that I would've killed for five or so years ago. Back then, I was trying to learn TDD basically on my own. Well, I had a great sounding board in Allan Halme, one of my colleagues at that time, but having this book would've made a big difference in how much time and effort it took to figure out the small stuff that makes a big difference. That was the last straw. I had no other choice but to make it happen!

Q: Is this your first book?
Yes, this is my first book. I've written articles before, for magazines as well as online, but I had no idea what it would be like.

Q: How easy or hard was it writing this book?
You've probably heard people say that writing a book is like giving birth? It's true. It took my almost three years to get it out!

There were a lot of surprises along the way. One of the hardest parts of the job was to write well. It was like a shell shock to find out how bad a writer I was back when I turned in the first draft chapters! Manning's editors did an amazing job in schooling me about the various techniques and nuances that make for a good text. I know for a fact
that the book wouldn't have been as good as it is if I didn't have such a fantastic staff to support me along the way.

The final finishing touches were a killer, too. I had no idea how much time and effort it would take to revise the manuscript based on reviews or how much time and effort it would take to create the index. The sheer amount of change that took place over these years was so huge that I think I wrote the book three times!

I have to admit, though, that I didn't really write the book for three years. There were several periods where I didn't work on the book for several months, focusing my energy on other stuff like work, learning, and having a personal life. Then I would pick up the manuscript again and work on a couple of chapters. Also, I was working full-time
throughout this project so that's already a big influence in how long it took in calendar time.

Q: How much time did you take to write this book?
As I said, the whole project took almost three years. To be more specific, two years and seven months. I started around February, 2005 and the final manuscript went to press in September, 2007. I didn't work on it all of that time, though, and I had long periods of zero productivity with regards to the manuscript so it's really difficult to give you a number. I once heard an estimate that writing a book takes 1,000 hours on average. That could very well be in the right ball park.

Q: When did you get the idea to write this book?
I actually got the idea from Manning. They asked if I'd be interested in writing something about TDD. I thought about it for a while, sketching a table of contents, and quite quickly came into the conclusion that I most certainly am interested and will write a book on TDD. That's the whole envy thing I mentioned before.

Q: Who is your target audience?
My target audience is developers. Mostly Java developers because I use Java for examples throughout but most all of the concepts I describe are equally well applicable to, for example, .NET development. It's just the APIs and language that are different. "Test Driven" is really such a comprehensive package that it has something for complete
TDD-newbies as well as for more experienced TDDers. Also, I'm quite confident that the text I've written about Acceptance Test Driven Development is valuable to almost any colleague whose looking into or is already doing Acceptance TDD.

Q: What specific technologies are you covering in this book?
I've tried to stay current with all technologies I've covered in the book. That means that all of the examples have been written in Java 5 and against a recent release of JUnit 4. Also, I've tried to pull in what I consider the most common open source frameworks such as Spring and Hibernate, as well as frameworks I consider the best kept secrets of the Java community, such as Apache Wicket.

Q: Do you show how to test EJB's(including 3.0) as well?
I most certainly do. In fact, we decided to make the chapter on test driving EJBs a bonus chapter available online from Manning's website (http://www.manning.com/koskela). Actually, often times it felt awkward to talk about testing EJB 3.0 components because it's gotten so much easier compared to the old EJB 2.x versions of the specification! Nevertheless, I talk about test driving session beans, testing for the container-component contracts, about dependency injection, faking the JNDI tree, and about testing the asynchronous stuff such as timers. It's not quite as straightforward as writing tests for plain old Java objects but it's certainly not as hard as people seem to think. I guess the pain of EJB 2 is still in our minds...

Q: What are the main things you learned while writing about TDD?
Wow. That's a tough question to answer. So much has happened during these years. Regarding TDD, I've certainly developed my sense of design as well as my concept of how TDD works best for me. I've also learned a lot about solving the kinds of technical problems I faced myself when I first started doing it.

Q: Now that you have written this book, If I can ask, what is the percentage of coverage you have in your code?
Coverage?
I'll have to check. You see, I'm not that much into measuring test coverage. To me it's more important that the tests I have are expressive and meaningful. The last project I checked the coverage for, it was well above 90%. I do get questioned a lot about
the magic 100% test coverage. I don't consider that a sensible "target" for Java code, though, because of some of the APIs we use. For example, I don't want to write a test for an exception that cannot happen in the context where I'm using the API and some people are just stubborn about throwing checked exceptions

Q: What would you like to say to developers who say they don't have time to write tests or that their code is too complicated to write any tests?
I would suggest they stop writing code immediately. Otherwise they'll soon be too busy fixing bugs that they won't have time to check the new content on JavaLobby!

Do you have questions for Lasse or did we miss something in the interview? Post your questions here and he'll try to answer them for you!

Purchase and support Javalobby