A few weeks ago, I attended Devoxx US in San Jose, CA, and gave a talk about JUnit 5. The recording is now available on YouTube.
I am resurrecting this blog for a very special occasion: we, the JUnit 5 team, have released the first milestone of JUnit 5 this Thursday. A tremendous amount of work has been completed since we shipped the alpha version in February: 138 issues have been resolved, 766 commits have been pushed to master. We had fruitful discussions with many contributors and early adopters. Thanks to everyone who participated and helped to make it happen!
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.
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.
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.
Long awaited, JUnit 4.8 introduced support for categorizing test cases.
A category marker is simply a class or interface, e.g.
public interface SlowTests {}
Using Hamcrest matchers in combination with assertThat allows for more fluid specification of JUnit assertions.
Recently, while working on the backend of Project Usus, we needed a simple matcher, that would test whether a given set is empty. At the time, we reused a set matcher we had already written a few minutes earlier.
The very first 4.x release of JUnit contained support for custom test runners. Moreover, it came with the Parameterized test runner that allows to execute the test cases in a test class against a collection of values, i.e. parameters.
Subscribe via RSS