DZone MVB Nicolas Frankel is working on his latest book, this time writing a book dedicated to integration testing. As one of the major pain points for anyone undertaking test driven development, this book is bound to be popular. Published on
leanpub, you'll be able to get your hands on it soon. For now, I spoke with Nicolas to find out more about the book, and some of his opinions on testing
DZone: What prompted you to write another book?
Nicolas: No rest for the wicked, I guess! In fact, after the release
Learning Vaadin 7, I felt very happy of course. But after some time, there was this feeling that I had to write again. I think this might not be different from what real litterature writers experience.
DZone: A book dedicated to integration testing is rare. What makes it stand out from other books that cover the testing process?
Nicolas: You're entirely right. In fact, my bibliography on this subject is quite small. The problem is once people find an interest in something, there are plenty of other people that want to make use of it. I find it's a huge step that a majority of software developers and projects now enforce unit testing and code coverage. But this is not enough: it is as if you wanted to test a final assembled car by testing every part separately. While it makes sense to test every nuts and bolts, you must also test drive their interaction. And that's the domain of integration testing.
DZone: Of all stages of test, what do you think is the most difficult stage to get right?
Nicolas: Unit testing has been extensively defined, documented and practiced. On the opposite side, there are many tools for end-to-end functional testing, as well as some experience. In the middle stands integration testing, with many tools available but very little practice; this leaves many software engineers with the trial-and-error strategy. Since I've done a lot of errors, I think it's good that other engineers also benefit from them.
DZone: Developers seem to find ways to get out of testing all the time. What encouragement can you give to those who still don't quite buy into the benefits of test driven development?
Nicolas: Hmm.... I don't know about TDD since I'm not a fierce proponent of it, but any aspiring developer should be put on a maintenance project with no tests and experience first-hands how hard it is to update code with no test harness.
DZone: How would you approach testing for a legacy project, which has very little, if any, tests available?
Nicolas: I would suggest refactoring to make the code testable, which require testing first. Quite a quandary! So I would definitely use an iterative strategy. First, create a very coarse-grained functional end-to-end testing harness. Then, during each iteration, set up a finer-grained testing on a specific area with the help of dedicated libraries such as PowerMock, refactor to a more unit-testing friendly design, then remove PowerMock.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}