I don’t know if events became part of software engineering since Graphical-User Interface interactions, but for sure they are a very convenient way of modeling them. With more and more interconnected systems, asynchronous event management has become an important issue to tackle. With Functional-Programming also on the raise, this gave birth to libraries such as RxJava. However, modeling a problem as the handling of a stream of events shouldn’t be restricted to system events handling.
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. This is the case when
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. The next chapter compares the respecti
Last week, I took some days off to attend Devoxx France 2014 3rd edition. As for oysters, the largest talks do not necessarily contain the prettiest pearls. During this year’s edition, my revelation came from a 15 minutes talk by my friend Alexandre Victoor, who introduced me to the wonders of Mutation Testing. Since I’m currently writing about Integration Testing, I’m very much interested in Testing flavors I don’t know about.
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. Unit Test vs Int
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. Creating the test artifact First, we have to use Maven: I kn
I really like Spring, so I tend to use its features to the fullest. However, in some dark corners of its philosophy, I tend to disagree with some of its assumptions. One such assumption is the way database testing should work. In this article, I will explain how to configure your projects to make Spring Test and DBUnit play nice together in a multi-developers environment.
This review is about Specifications by Example by Gojko Adzic from Manning. Facts 18 chapters, 254 pages, $29.21This book covers Specifications by Example (you could have guessed it from the title). In effect, SBE are a way to build the right software (for the customers), as opposed to build the software right (which is our trade as engineers). Specification by Example is a set of process patterns that facilitate change in software products to ensure that the right product is delivered effic
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. If you write a line o
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. One could think everything has been said and done for unit testing and we should move forward to a more w
Software testing traditionally has been separated between unit testing - testing classes in isolation - and integration testing - testing across all layers. Whereas unit testing is the domain of developers, integration testing is the domain of analysts. Moreover, most of the time, those tests are not automated and are painfully reexecuted by hand each time they are needed. This means that your build process has a safeguard harness on the unit level but nothing on the feature level (at least nothi
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. Both are interfaces that have