Unit Testing mandates to test the unit in isolation. In order to achieve that, the general consensus is to design our classes in a decoupled way using DI. In this paradigm, whether using a framework or not, whether using compile-time or runtime compilation, object instantiation is the responsibility of dedicated factories. In particular, this means the new keyword should be used only in those factories. Sometimes, however, having a dedicated factory just doesn’t fit.

Writing a book is a journey. At the beginning of the journey, you mostly know where you want to go, but have only vague notion of the way to get there and the time it will take. I’ve finally released the paperback version of Integration Testing from the Trenches on Amazon and that means this specific journey is at end. The book starts by a very generic discussion about testing and continues by defining Integration Testing in comparison to Unit Testing.

This post is the written form of one of my submission for Devoxx France 2013. As it was only chosen as backup, I lacked the necessary motivation to prepare it. The subject is important though, so I finally decided to write it down. In 2013, if you’re a standard developer, it is practically a given that you test your code. Whether you’re a practicioner of TDD or just create them afterwards, most realize a robust automated test harness is not optional but mandatory.

Sometimes, you need to reuse your test classes across different projects. These are two use-cases that I know of: Utility classes that create relevant domain objects used in different modulesDatabase test classes (ans resources) that need to be run in the persistence project as well as the integration test project Since I’ve seen more than my share of misuses, this article aim to provide an elegant solution once and for all.

The basis of this article is a sequences of tweets betwen me and M. Robert Martin, on April 8th 2011: If you have 100% coverage you don’t know if your system works, but you do know that every line you wrote does what you thought it should.@unclebobmartin 100% code coverage doesn’t achieve anything, save making you safer while nothing could be further from the truth.@nicolas_frankel 100% code coverage isn’t an achievement, it’s a minimum requirement.

Ten years ago, the only tests we knew of were users acceptance tests. The last decade saw a gigantic leap forward: it brought unit testing. Unit testing was made popular with JUnit. In turn, TestNG added annotations to the test classes, making them ever easier. Then, EasyMock provided the means to mock our class dependencies in a test context while Mockito streamlined the process of doing so.

Whether you choose to choose to adopt TDD or a more traditional approach, you will test your classes in isolation. This usually mean you code with interfaces and inject your dependencies in your classes. Last year, I had to test a servlet. Servlets are the showcase to demonstrate out-of-container testing because of their dependencies to said container in their doXxx() method. Every one of these methods has a dependency on HttpServletRequest and HttpServletResponse.