Schauderhaft » Rule

Testing Databases with JUnit and Hibernate Part 1: One to Rule them

Jens Schauder — Sun, 13 Mar 2011 21:01:25 +0000

Databases are an extremely important part of almost every enterprise application. Yet there is very little support for testing your database, which results in very little tests coverage of database related code out in the wild. In a desperate attempt to change that at least a little the article series starting with this article will describe some of the problems and possible partial solutions based on Hibernate and JUnit.
As an example I use the following little set of Hibernate entity classes and the database schema Hibernate will create from it:

@Entity
public class SuperHero extends AbstractEntity {
@NotEmpty
@Column(unique = true)
public String name;
@ManyToOne
@NotNull
public SuperPower power;
@NotEmpty
public String weakness;
@NotEmpty
public String secretIdentity;
}

@Entity
public class SuperPower extends AbstractEntity {
@NotEmpty
@Column(unique = true)
public String name;
@NotEmpty
public String description;
@NotNull
@ManyToOne
public SuperPowerType type;
}

@Entity
public class SuperPowerType extends AbstractEntity {
@NotEmpty
@Column(unique = true)
public String name;
@NotNull
@Length(min = 30)
public String description;
}

As you can see (and if you don’t I tell you) a SuperHero references a SuperPower and a SuperPower references a SuperPowerType. All have some mandatory attributes.
All three entities have a common supertype providing id and version.

@MappedSuperclass
public class AbstractEntity {
@SuppressWarnings("unused")
@Id
@GeneratedValue
public Long id;
@SuppressWarnings("unused")
@Version
private Long version;
}

For brevity I skipped on getters and setters.

Finally there is a SuperHeroRepository which I want to test. It has a single method returning a SuperHero based on the a SuperPower
A simple test for the SuperHeroRepository might work like this:

Create a SuperHero and make sure I can retrieve it again using the SuperHeroRepository.

Easy, isn’t it? Well … lets see what you really have to do

create an empty database
create a SuperPowerType, making sure you have all the mandatory fields filled
create a SuperPower of that type, making sure you have all the mandatory fields filled
create a SuperHero, making sure you have all the mandatory fields filled
use the repository to retrieve SuperHeros
assert you got the expected result.

So we have to fill all the mandatory fields and provide a SuperPowerType (again with all the mandatory fields) although nothing in the test is concerned with SuperPowerTypes. If you still don’t believe this results in ugly code have a look at this naive implementation.

public class SuperHeroRepository1Test {
private SessionFactory sessionFactory;
private Session session = null;
@Before
public void before() {
// setup the session factory
AnnotationConfiguration configuration = new AnnotationConfiguration();
configuration.addAnnotatedClass(SuperHero.class)
.addAnnotatedClass(SuperPower.class)
.addAnnotatedClass(SuperPowerType.class);
configuration.setProperty("hibernate.dialect",
"org.hibernate.dialect.H2Dialect");
configuration.setProperty("hibernate.connection.driver_class",
"org.h2.Driver");
configuration.setProperty("hibernate.connection.url", "jdbc:h2:mem");
configuration.setProperty("hibernate.hbm2ddl.auto", "create");
sessionFactory = configuration.buildSessionFactory();
session = sessionFactory.openSession();
}
@Test
public void returnsHerosWithMatchingType() {
// create the objects needed for testing
SuperPowerType powerType = new SuperPowerType();
powerType.name = "TheType";
powerType.description = "12345678901234567890aDescription";
SuperPower superpower = new SuperPower();
superpower.name = "SuperPower";
superpower.description = "Description";
superpower.type = powerType;
SuperHero hero = new SuperHero();
hero.name = "Name";
hero.power = superpower;
hero.weakness = "None";
hero.secretIdentity = "Mr. Jones";
// storing the objects for the test in the database
session.save(powerType);
session.save(superpower);
session.save(hero);
SuperHeroRepository heroRepository = new SuperHeroRepository(session);
List<SuperHero> heroes = heroRepository.loadBy(superpower);
assertNotNull(heroes);
assertEquals(1, heroes.size());
}
@After
public void after() {
session.close();
sessionFactory.close();
}
}

There is really only one positive thing I can say about this test: it uses H2 in In-Memory mode so it is reasonable fast. There is the first lesson: *Use an in memory database for testing if possible. It’s easily 100*faster then a disc based database*

So obviously we want to refactor this monster, which might after some method extracting result into something like this:

public class SuperHeroRepository2Test {
private SessionFactory sessionFactory;
private Session session;
@Before
public void before() {
sessionFactory = createSessionFactory();
session = sessionFactory.openSession();
Transaction transaction = session.beginTransaction();
}
@Test
public void returnsHerosWithMatchingType() {
SuperPowerType powerType = createSuperPowerType();
session.save(powerType);
SuperPower superpower = createSuperPower(powerType);
session.save(superpower);
SuperHero hero = createSuperHero(superpower);
session.save(hero);
SuperHeroRepository heroRepository = new SuperHeroRepository(session);
List<SuperHero> heroes = heroRepository.loadBy(superpower);
assertNotNull(heroes);
assertEquals(1, heroes.size());
}
private SessionFactory createSessionFactory() {
AnnotationConfiguration configuration = new AnnotationConfiguration();
configuration.addAnnotatedClass(SuperHero.class)
.addAnnotatedClass(SuperPower.class)
.addAnnotatedClass(SuperPowerType.class);
configuration.setProperty("hibernate.dialect",
"org.hibernate.dialect.H2Dialect");
configuration.setProperty("hibernate.connection.driver_class",
"org.h2.Driver");
configuration.setProperty("hibernate.connection.url", "jdbc:h2:mem");
configuration.setProperty("hibernate.hbm2ddl.auto", "create");
SessionFactory sessionFactory = configuration.buildSessionFactory();
return sessionFactory;
}
private SuperHero createSuperHero(SuperPower superpower) {
SuperHero hero = new SuperHero();
hero.name = "Name";
hero.power = superpower;
hero.weakness = "None";
hero.secretIdentity = "Mr. Jones";
return hero;
}
private SuperPower createSuperPower(SuperPowerType powerType) {
SuperPower superpower = new SuperPower();
superpower.name = "SuperPower";
superpower.description = "Description";
superpower.type = powerType;
return superpower;
}
private SuperPowerType createSuperPowerType() {
SuperPowerType powerType = new SuperPowerType();
powerType.name = "TheType";
powerType.description = "12345678901234567890aDescription";
return powerType;
}
}

This would be ok, if this would be the only test of this kind. But other similar test need the SessionFactory as well so I will move all the SessionFactory, Session and Transaction stuff into a Rule

public class SessionFactoryRule implements MethodRule {
private SessionFactory sessionFactory;
private Transaction transaction;
private Session session;
@Override
public Statement apply(final Statement statement, FrameworkMethod method,
Object test) {
return new Statement() {
@Override
public void evaluate() throws Throwable {
sessionFactory = createSessionFactory();
createSession();
beginTransaction();
try {
statement.evaluate();
} finally {
shutdown();
}
}
};
}
private void shutdown() {
try {
try {
try {
transaction.rollback();
} catch (Exception ex) {
ex.printStackTrace();
}
session.close();
} catch (Exception ex) {
ex.printStackTrace();
}
sessionFactory.close();
} catch (Exception ex) {
ex.printStackTrace();
}
}
private SessionFactory createSessionFactory() {
AnnotationConfiguration configuration = new AnnotationConfiguration();
configuration.addAnnotatedClass(SuperHero.class)
.addAnnotatedClass(SuperPower.class)
.addAnnotatedClass(SuperPowerType.class);
configuration.setProperty("hibernate.dialect",
"org.hibernate.dialect.H2Dialect");
configuration.setProperty("hibernate.connection.driver_class",
"org.h2.Driver");
configuration.setProperty("hibernate.connection.url", "jdbc:h2:mem");
configuration.setProperty("hibernate.hbm2ddl.auto", "create");
SessionFactory sessionFactory = configuration.buildSessionFactory();
return sessionFactory;
}
public Session createSession() {
session = sessionFactory.openSession();
return session;
}
public void commit() {
transaction.commit();
}
public void beginTransaction() {
transaction = session.beginTransaction();
}
public Session getSession() {
return session;
}
}

Which leaves the test in a somewhat acceptable state.

public class SuperHeroRepository3Test {
@Rule
public final SessionFactoryRule sf = new SessionFactoryRule();
@Test
public void returnsHerosWithMatchingType() {
Session session = sf.getSession();
SuperPowerType powerType = createSuperPowerType();
session.save(powerType);
SuperPower superpower = createSuperPower(powerType);
session.save(superpower);
SuperHero hero = createSuperHero(superpower);
session.save(hero);
sf.commit();
SuperHeroRepository heroRepository = new SuperHeroRepository(session);
List<SuperHero> heroes = heroRepository.loadBy(superpower);
assertNotNull(heroes);
assertEquals(1, heroes.size());
}
// … private methods more or less as before
}

All the SessionFactory creation is now moved out into a Rule and is therefore perfectly reusable. You now can change the way you create your SessionFactory at a single point for all tests in need of a database. This is nice and it shall be enough for today. Next week we’ll take care of our SuperHero and her dependencies.

Use Cases for JUnit Rules

Jens Schauder — Sun, 15 Aug 2010 08:12:25 +0000

Sometime ago I blogged about JUnit @Rule Annotation. In the meantime I got the chance to use rules in a real project. I must say: Rules rock! Let me tell you about my use cases.

I am working on a Swing project (It’s OK, it’s not as bad as it sounds). We have many tests that create components and check certain properties. Although they never get shown in the traditional sense, Swing documentation requires all manipulation of Swing Components to happen in the Event Dispatch Thread. We have an EDTRule, which runs every test using SwingUtilities.invokeAndWait(). It works like a charm. We actually had a dozen tests that would fail under real weird conditions, which behave nicely since they where adorned with an EDTRule. While the Rule takes care on the threading requirements, test stay nicely clean and don’t get poluted by SwingUtilities and Runnable implementations.
Another class of tests runs scripts against a database. In order to reproduce what the database admins will do, we use SQL/Plus for this (If you don’t know SQL/Plus consider yourself lucky). One problem with these test is, that a small bug in a script might cause SQL/Plus to await user input. In order to prevent the test to hang forever we implemented a TimeoutRule. Each script that gets started puts its Process instance into the rule instance, and the rule instance will destroy the Process after some specified time. Note: JUnit comes with a similar Timeout rule, which will let the test fail after a timeout.
We have an ApplicationRegistry, which is basically a singleton map containing Implementations for Interfaces. Each test should setup the ApplicationRegistry with whatever is needed, and clean it up afterwards. Often developers forget the last part (When I say developers I am talking about myself). For this we have an ApplicationRegistryRule. It cleans the ApplicationRegistry before the test and after the test. Since it is only one Rule instead of a Before and an After method, it is easier not to forget one half of it. But the Rule does more: Before cleaning it, it checks if the ApplicationRegistry is empty. If it isn’t this means, some other test left it dirty. In this case the Rule calls Assertion.fail(). This way we found (probably) every test which left the ApplicationRegistry dirty. Very cool. A similar approach should work for other central resources like Spring Contexts and the like.

New Feature of JUnit: Rules

Jens Schauder — Sun, 04 Oct 2009 10:12:20 +0000

card board box

I am always surprised how many unknown feature hide in a supposedly simple library. Todays example is JUnit. When inspecting the newest version (4.7) I noted an annotation I hadn’t noticed before: @Rule. WTF? I am looking at a testing framework and not at a rules engine, am I? So naturally I tried to find out what it is good for, and since not to much documentation is available my little research resulted in this blog post. Enjoy.

The purpose of the @Rule annotation is to mark public fields of a test class. These fields must be of type MethodRule, or an implementing class. Such MethodRules behave similar to a AOP aspects, of course without use of any AOP library and specialized for Tests. They can execute code before, after or instead of a test method. Example use cases listed in the release notes include:

Notification on tests
Setting up or tearing down resources, especially when they are used in multiple test classes
Special checks performed after every test, possibly causing a test to fail.
Making information about the test available inside the test

But ready made examples are boring, so I decided to try to implement something I was looking for all the time.

When writing acceptance tests with Fit or a similiar framework, you might end up with tons of failing tests, simply because the features aren’t implemented yet. But I don’t want this red lights hide a real red light, i.e. a test that worked before, but fails now. Therefore I’d like tests to get ignored just as if they where accordingly annotated, until they succeed for the first time. After that they should run (and possibly fail) just as a normal.

Let’s get started. First we need a little test case that can fail or succeed as we want. And this test case of course needs our annotated field:

public class DummyTest {

@Rule
public IgnoreLeadingFailure ilf = new IgnoreLeadingFailure();
@Test
public void testTest() {
assertTrue(false);
}
}

Please note that I stripped all package and import statements for brevity. As you can see I already named my MethodRule implementation IgnoreLeadingFailure. It needs some way to track which tests ran successfully at least once. Since I am lazy, I stored this information in a property file.

public class IgnoreLeadingFailure implements MethodRule {

private final static String PROPERTY_FILE_NAME = "activatedTests.properties";
private final static Properties activatedTests = new Properties();
static {
try {
activatedTests.load(new FileInputStream(PROPERTY_FILE_NAME));
} catch (IOException e) {
// actually this is to be expected on the first run
System.out.println("Couldn't load Properties from file" + e);
}
}
public Statement apply(final Statement base, final FrameworkMethod method,
final Object target) {
if (activatedTests.containsKey(getFullTestMethodName(method, target))) {
return base;
} else {
return new Statement() {
@Override
public void evaluate() throws Throwable {
try {
base.evaluate();
activateTest(getFullTestMethodName(method, target));
} catch (Throwable t) {
throw new AssumptionViolatedException(
"This test never succeeded before, and failed again with: "
+ t.toString());
}
}
private void activateTest(String fullTestMethodName) {
activatedTests.put(fullTestMethodName,
new SimpleDateFormat().format(new Date()));
try {
activatedTests.store(new FileOutputStream(
PROPERTY_FILE_NAME),
"tests that ran successfully at least once");
} catch (IOException io) {
System.out.println("failed to store properties" + io);
}
}
};
}
}
private String getFullTestMethodName(final FrameworkMethod method,
Object target) {
return target.getClass().getName() + " " + method.getName();
}
}

The interesting part is the single method contained in the MethodRule interface:

public Statement apply(final Statement base, final FrameworkMethod method, final Object target)

base is the object that encapsulates the execution of the test method. The purpose of apply(..) is to provide a Statement. This Statement will get executed (or in the lingo of the interface ‘evaluated’). Typically you’ll return a Statement implementation, that wraps the Statement instance passed as a parameter.

method is the test method that will eventually get called and

target is the object containing that method. Note that you normally do not execute the method, but use it mainly to get more information about the test case the MethodRule is applied to.

With this information it should be easy to understand what my little class does: It checks if the test at hand was already executed successfully before. If this is the case, the same Statement is returned, that was passed as a parameter. Otherwise an anonymous implementation is returned which replaces any failure by a AssumptionViolatedException, and saves a successful test run in the property file. Note that the AssumptionViolatedException actually does not result in a ignored test, but gets displayed as a successful test, at least with the default runner, which doesn't really fit my needs, but one could easily fix that by a minor change in the runner but not without that change.

So here is my opinion about this new JUnit feature: It certainly can come in handy for (integration) tests, where one tends to need a lot of resources that need quite some setup and/or tear down. Implementation of a MethodRule is fairly easy, although not exactly straight forward. The biggest problem is that it is next to impossible for an average java developer who doesn't know this feature to understand what is going on. The annotated field is easily missed, since in many cases it isn't used at all in the test class. Once more all this could be straight forward when java would support natively things like aspect oriented programming or open classes.

If you want more information I suggest you drop by this blog post about 'Interceptors' which was the name for rules at the time of writing of that post.

So, what do you think of this feature? Any ideas for features that could be implemented using rules?