JUnit file structure, best practices (helper classes placement)

Question

Established standards

I organize my code, so that my test-folder has the same packages as my main-folder. My test classes, are named the same as my classes, but with Test appended.

So far so good.

Problem

I find myself creating a util-package in my test-folders, on my projects. And there I keep some project specific "test helper classes".

src  
│
└───main
    │   
    ├───java
    │   │
    │   ├─── myPackage
    │        MyClass.java
    │        AnotherClass.java
    │
    ├───test
        │
        ├─── myPackage
        │    MyClassTest.java
        │    AnotherClassTest.java
        │
        ├─── util
             NiceTestUtil.java

The "problem" is that I hate the asymmetry. A util-package in test, feels like it should be testing corresponding util-packages in main. Instead it contains my helper classes.

I've been thinking that maybe the util package belongs in main, but that doesn't feel right either, since it will clutter up main.

I use JUnit 4.11, and Gradle (if it matters to anyone).

Question:

What is considered the best practice, file structure, for "test helper classes"?

Answer 1

Placing the class into test part of project is correct.

The only thing that may help you: If the NiceTestUtil is used only for tests in myPackage, you can move that class to that package.

If it may be used by tests from other packages, I think you will have to live with this asymmetry :-)

There is nothing bad with it. It is a good practice to have symmetry in a way that production class -> test class. But it does not apply necessarily the other direction test class -> production class.

The last thing that comes on my mind is: If your NiceTestUtil can be used across projects, you can create a separate artifact (project) for it and use it as test-scoped dependency. This will remove asymmetry but for the cost of maintenance two projects (but removes possible NiceTestUtil code duplicity in future).

Answer 2

My own rules for organizing classes in the test part are the same that for the main part: Minimize always its visibility:

• An API (method/class/etc) usable just for one class, should be private.
• If it is usable by several classes in the same package, should be public and be in a class with package access.
• If it is usable by several classes in other packages, should be in a public class in the most proper package.
• If it is usable by several projects, should be in its own library.

So far, so obvious. But with tester APIs, I follow two more rules:

• Keep a package structure parallel to the main part.
• Keep the testers as simple as possible, because the testers should be reliable, and if they are complex, they would deserve to be tested. In other words: Favour simplicity over reusability.