Question

My unit tests need supplementary classes, mostly as factories for creating objects of classes under test. For example:

// EmployeeTest.java
public class EmployeeTest {
  @Test public void testName() {
    Employee emp = EmployeeTestFactory.get(); // static method
    assert(emp.getName() instanceof String);
  }
}
// SalaryTest.java
public class SalaryTest {
  @Test public void testAlwaysPositive() {
    Employee emp = EmployeeTestFactory.get(); // static method
    assert(emp.getSalary() > 0);
  }
}

As you see, I need to work with an instance of class Employee in both unit tests. I would like to create a simple factory, which will create such objects, on demand, e.g.:

public class EmployeeTestFactory {
  public static Employee get() {
    // create it, make persistent, fill with data
    // and return
  }
}

Is it a correct approach? If yes, where should I place this class? Right next to unit tests? Or maybe this factory is a sort of “resource”?

Answer 1

For me this a question of test data handling.

There are several approaches to handle test data:

1. Build them inside the junit classes.
   pros: you see what you have in the junit class.
   cons: You can’t reuse them.

2. Create Factories which creates the testdata.
   pros: Corse grained reuse is guaranteed
   cons: Fine grained reuse is not possible in a good structured way (when you need testdata with distinct attribute values), you can only access your testdata inside the the project, when you build with maven.
   The builder en.wikipedia.org/wiki/Builder_pattern and the object mother pattern martinfowler.com/bliki/ObjectMother.html are useful in this case.
   Here is a comparsion: geekswithblogs.net/Podwysocki/archive/2008/01/08/118362.aspx

3. Create Factories in an own project.
   pros: you can use your testdata in the other projects
   cons: you have an additional project to manage

My Favorite:

I like the most to have an own project. When the domain objects have interfaces, you can build jaxb implementations of them and hold the testdata in xml. For readability and reuse the best approach for me. You must then only say which xml testdata set to load.

If this is overkill I like the builder pattern with the fluent interface:

 Employee.build.name("Bob").age(32).street("teststreet");

Your Case:

I would hold them under the same package name like the domain classes and add the package testdata at the end. I wouldn’t name the factory method only get. Give it a name which is meaningful.

If you need an example how to use an inmemory database with spring, hibernate and junit, here is an example: http://little-tdd-project.origo.ethz.ch/