jUnit ignore @Test methods from base class

Question

Let's say I have a test class called testFixtureA with several methods testA, testB, testC, etc, each with @Test annotation.

Let's now say I subclass testFixtureA into class called testFixtureAB and I don't overwrite anything. testFixtureAB is empty as for now.

When I run tests from testFixtureAB, methods testA, testB and testC are executed by test runner because test runner doesn't distinguish between test methods from class and baseclass.

How can I force test runner to leave out tests from baseclass?

Solution 1

Restructure your test classes.

• If you don't want to use the tests from the baseclass, then don't extend it
• If you need other functionality from the base class, split that class in two - the tests, and the other functionality

Solution 2

and I don't overwrite anything. testFixtureAB is empty as for now

There's your answer. If you want to not run testB from the main class, overrride it:

public class testFixtureAB extends testFixtureA {
   @Override
   public void testB() {}
}

Solution 3

ignoring the whole base class:

@Ignore
class BaseClass {
   // ...
}

check out this example

Solution 4

It's quite easy to achieve implementing some few classes:

• Create your own TestRunner
• Create an annotation like @IgnoreInheritedTests
• Create a class that extends org.junit.runner.manipulation.Filter

On the filter class:

public class InheritedTestsFilter extends Filter {

    @Override
    public boolean shouldRun(Description description) {
        Class<?> clazz = description.getTestClass();
        String methodName = description.getMethodName();
        if (clazz.isAnnotationPresent(IgnoreInheritedTests.class)) {
            try {
                return clazz.getDeclaredMethod(methodName) != null;
            } catch (Exception e) {
                return false;
            }
        }
        return true;
    }

    @Override
    public String describe() {
        // TODO Auto-generated method stub
        return null;
    }

}

on your custom runner:

 /**
 * @param klass
 * @throws InitializationError
 * @since
 */
public CustomBaseRunner(Class<?> klass) throws InitializationError {
    super(klass);
    try {
        this.filter(new InheritedTestsFilter());
    } catch (NoTestsRemainException e) {
        throw new IllegalStateException("class should contain at least one runnable test", e);
    }
}

Solution 5

In Junit 5, you can make base class as abstract and extends it with a concrete class.

When you run the abstract in your IDE, your subclass will get executed instead.

View more solutions

Comments

[whiskeysierra]

This will ignore the base class everywhere, making it basically useless.

[user7610]

Make the base class abstract?

[Kevin Zhao]

to clarify for others since I didn't understand this answer when I first saw it, let's say you have method testB in base class annotated with @Test, and you don't want testB test to run in your subclass, then go to subclass, override this testB method, then this test will no longer run in your subclass

[Mike Burton]

This is unhelpful for the reason that @martosoler points out in the answer below - there are obvious cases (in my situation, Selenium tests against different browsers) where this is very bad advice. You want the same behaviour sometimes; only the setup of your "SUT" variable(s) differs between subclasses.

[Matthew Flynn]

@MikeBurton - Actually, this is good advice, although it may not be obvious what Bozho is suggesting. What you need to do is refactor your base class, extracting the code that should be reused into a new, (abstract) proto-base class. Your new test class would then extend the proto-base class rather than what we were calling the base class. This would be a good example of following the LSP and the general rule that you should never override concrete implementations. If you don't mind breaking those rules, you can go with my recommendation below.

[Mike Burton]

I don't actually know why I was objecting to this back in July. This is exactly the solution I landed on eventually. Although it feels at this point like there's an AOP solution that would solve my specific problem better. I'm not ambitious enough to solve it at the moment, however.