JUnit @Parameterized function is run before @BeforeClass in a test suite?

Question

I am using a JUnit test suite to run a few tests, one of which is run multiple times using @Parameterized. I am finding that when I run my tests, the @Parameterized function is run before @BeforeClass. Is this expected behavior or is something else happening? I would have expected that @BeforeClass would run before any of the tests are started.

Here is my test suite:

@RunWith(Suite.class)
@SuiteClasses({ Test1.class, Test2.class })
public class TestSuite {

    @BeforeClass
    public static void setup() throws Exception {
        // setup, I want this to be run before anything else
    }

}

Test1 uses @Parameterized:

public class Test1 {

    private String value;

    // @Parameterized function which appears to run before @BeforeClass setup()
    @Parameterized.Parameters
    public static Collection<Object[]> configurations() throws InterruptedException {

        // Code which relies on setup() to be run first

    }

    public Test1(String value) {
        this.value = value;
    }

    @Test
    public void testA() {
        // Test  
    }
}

How can I fix this to run the @BeforeClass setup() function before running anything else?

Solution 1

This is, unfortunately, working as intended. JUnit needs to enumerate all of the test cases before starting the test, and for parameterized tests, the method annotated with @Parameterized.Parameters is used to determine how many tests there are.

Solution 2

Although beeing a bit different solution, a static block does the trick. Also note, that it must be in the Test1.class. But beside of that it works ;-)

@RunWith(Parameterized.class)
public class Test1 {

    static{
        System.out.println("Executed before everything");
    }

    private String value;

    // @Parameterized function which appears to run before @BeforeClass setup()
    @Parameterized.Parameters
    public static Collection<Object[]> configurations() throws InterruptedException {
        // Code which relies on setup() to be run first
    }

    public Test1(String value) {
        this.value = value;
    }

    @Test
    public void testA() {
        // Test  
    }
}

Solution 3

Recently ran into similar issue and solved problem using Function. Example below.

@RunWith(Parameterized.class)
public class MyClassTest {

    @Parameterized.Parameters
    public static Iterable functions() {
        return Arrays.<Object, Object>asList(
            param -> new Object()
        );
    }

    Object param;
    Function function;

    public MyClassTest(Function f) {
        this.function = f;
    }

    @Before
    public void before() {
        // construct dependency
        param = "some value";
    }

    @Test
    public void test() {
        assertThat(myClass.doSomething(function.apply(param)), is(equalTo(expectedValue)));
    }
}

In your scenario, do database setup in @Before or @BeforeClass then inject into function

Comments

[Corey Wu]

Okay thanks, do you have any suggestions on how to implement the functionality that I am looking for?

[NamshubWriter]

@CoreyWu could you let us know what exact problem you are trying to solve?

[bobanahalf]

I have this problem, too. I'm trying to do database prep before I set up my tests. My @Parameters method queries the database to find test values. I'd like to set up the database before getting my test values. No, this is not strictly unit testing....

[NamshubWriter]

@bobanahalf You could try setting up the database in your @Parameters method, but if it fails I'm not sure if JUnit will make the root cause of the error obvious. Personally I wouldn't use Parameterized if my parameters were from a data source that could fail or was slow to query.

[bobanahalf]

@NamshubWriter, do you know another way to dynamically discover test data? We're running our tests over different databases. Even if it was all one database, I wouldn't really be able to count on today's data being the same as next month's. For now, I've got my discovery code in a static initializer. I'm sure there are undesirable side-affects if my initializer doesn't behave as I hope.

[NamshubWriter]

@bebanahalf I don't know of another way to dynamically discover data. I recommend never calling code that could fail in a static initializer.