Recently, we have released JUnit 4.11 which now uses the latest version of Hamcrest (1.3). Being finally able to (easily) use the power of a recent version of the matchers that come with hamcrest-core and hamcrest-library along with JUnit, I have been looking for a decent-looking printable quick reference of available matchers. Since I wasn’t able to find any, I have decided to create my own.
A little more than a month ago I spoke at the Entwicklertag in Karlsruhe about Software Craftsmanship. More precisely, I gave my very first Pecha Kucha on my understanding of the principles and ethics behind it.
A couple of weeks ago I had the pleasure to participate in Uncle Bob’s Clean Code course in Karlsruhe. Afterwards, I interviewed him together with Susann Mathis on Software Craftsmanship and professionalism in software development.
In the previous post we have seen how to use DbUnit to write a simple database test. By using DbUnit for this purpose, we were able to insert a complete dataset into the database without writing SQL. However, we had to use XML to specify the dataset:
<dataset> <PERSON NAME="Bob" LAST_NAME="Doe" AGE="18"/> <PERSON NAME="Alice" LAST_NAME="Foo" AGE="23"/> <PERSON NAME="Charlie" LAST_NAME="Brown" AGE="42"/> </dataset>
Now, you can think about XML what you want but I (and hopefully most people) would rather not want to write such files but instead create the dataset directly in the code of the test class. As it turns out, this is very hard using plain DbUnit.
Inspired by a recent blog post and presentation by Jens Schauder, this blog posts starts a series of posts about using DbUnit for database and integration tests. In addition, I will talk about Database Tests with DbUnit at ObjektForum Karlsruhe in April. This first post introduces DbUnit and demonstrates how it can be used to write database tests.
Marc Philipp, andrena objects ag
Stefan Birkner, Immobilien Scout GmbH
Erschienen in Java aktuell, 1/2012, dem Magazin der iJUG.
Automatisierte Tests sind aus der heutigen Softwareentwicklung nicht mehr wegzudenken. JUnit ist das älteste und bekannteste Testing-Framework für Java. Doch selbst ein so etabliertes und einfach zu benutzendes Framework wird kontinuierlich weiterentwickelt. Eine der Neuerungen sind JUnit Rules, die Entwicklern eine neue mächtige Möglichkeit bieten, Tests zu formulieren und besser zu strukturieren.
The Hamcrest project provides a large number of matchers, i.e. declaratively defined predicates. Prominent uses of these matchers include testing and mocking libraries like JUnit and jMock, respectively.
One of the benefits of using
assertThat() and Hamcrest matchers is that assertions become very readable. Unfortunately, you often have to rely on a questionable Java mechanism: auto boxing/unboxing.
In a recent commit to JUnit Kent Beck and David Saff have added an “alpha-ready implementation of
SuiteBuilder”. As Kent Beck previously described in a blog post, the idea behind the
SuiteBuilder runner is to use annotations on fields instead of annotations on classes.
Subscribe via RSS