Difference Between @Before, @Beforeclass, @Beforeeach and @Beforeall

Difference between @Before, @BeforeClass, @BeforeEach and @BeforeAll

The code marked @Before is executed before each test, while @BeforeClass runs once before the entire test fixture. If your test class has ten tests, @Before code will be executed ten times, but @BeforeClass will be executed only once.

In general, you use @BeforeClass when multiple tests need to share the same computationally expensive setup code. Establishing a database connection falls into this category. You can move code from @BeforeClass into @Before, but your test run may take longer. Note that the code marked @BeforeClass is run as static initializer, therefore it will run before the class instance of your test fixture is created.

In JUnit 5, the tags @BeforeEach and @BeforeAll are the equivalents of @Before and @BeforeClass in JUnit 4. Their names are a bit more indicative of when they run, loosely interpreted: 'before each tests' and 'once before all tests'.

What is difference between BeforeClass (Junit 4 ) and BeforeEach(Junit5)

The main functionality added is more fine-grained control over the Test Instance Lifecycle, for example through @TestInstance annotations. I presume this was one of the reasons to change the names of the old @Before and @BeforeClass annotations.

The old (JUnit4) @Before and the new (JUnit5) @BeforeEach are similar in that they are executed anew before every @Test method in a test class. So if your class has 10 test methods, the @BeforeEach method is executed 10 times.

The old (JUnit4) @BeforeClass and the new (JUnit5) @BeforeAll are similar in that they are both executed just once, before any of the tests in the class. So even if your class has 10 tests, the @BeforeAll method is executed just once.

The suggestion made in the question that @BeforeClass was renamed to @BeforeEach is thus incorrect.

For more information, see also this question on the difference between @Before, @BeforeClass, @BeforeEach and @BeforeAll.

What is the difference between beforeAll and writing at the top of the code?

When you have asynchronous functions (async/promise) that need to run, without boilerplate code, they may not complete before the tests start, by using before all or after all, you ensure that the async function call resolves before starting.

Additionally, Using a method like beforeAll or afterAll enable one-time setup/teardown functions to be called. If these fail (throw exceptions) then the framework knows that all subsequent tests will fail and to not run them.

You can read more about setup/teardown methods here.

BeforeAll vs. BeforeEach. When to use them?

Both are used to set up whatever conditions are needed for one or more tests.

If you're certain that the tests don't make any changes to those conditions, you can use beforeAll (which will run once).

If the tests do make changes to those conditions, then you would need to use beforeEach, which will run before every test, so it can reset the conditions for the next one.

Unless the initialization is slow or computationally expensive, it may be safest to default to using beforeEach as it reduces the opportunity for human error, i.e. not realizing that one test is changing the setup for the next one.

The sample you showed is a good example of using both in combination -- the slow network call is put in beforeAll, so it only has to happen once; and the data object (which is presumably modified by the tests) is reset each time in beforeEach.

JUnit using @Before over @BeforeClass

Each test should be isolated. By using BeforeClass then the state of the previous test could be hanging about and messing up the later tests.

One generally uses BeforeClass to setup an expensive external resource and Before to reset the world (be that the external resource or local).

One final note:

performs better/faster

In this case I would say the two properties should be treated independently here (that is better!=faster). As long as the total time to run your complete tests suite is under 10 minutes then "faster" is simply not important.

Once you go above that magic ten minutes (and at this point you will definitely be talking integration tests not unit tests) then start looking for ways to make things "faster".

What is the convention for @BeforeClass (@BeforeAll) and @AfterClass (@AfterAll) method names?

setUp() and tearDown() only exist as conventions because those were the hard coded names of the methods in JUnit 3's TestCase. Thus, prior to JUnit 4 those methods had to be named exactly that.

Since JUnit 4, developers are free to name setup and tear-down methods anything they want. The same applies to JUnit Jupiter.

Some people prefer to continue to name them setUp() and tearDown(). Some people prefer to simply name them after the annotations, such as before()/beforeEach() and after()/afterEach(). Some people prefer to name them something meaningful like prepareMock() and verifyMockInvocations().

So, in the end it's really just a matter of preference.

JUnit 3 did not have class-level lifecycle callback methods. Consequently, there are no corresponding legacy conventions like with setUp() and tearDown(). As for what to call them, the same "preference rules" apply to those methods. Call them whatever you like!

@BeforeClass Method not runing before each class

You can make a BaseTest class with @BeforeClass annotation and then each Test class extend with BaseTest.

BaseTest:

public class BaseTest {
    @BeforeClass
    public void test1() {
        System.out.println("printing Before Class Method");
    }
}

Test1:

public class Test1 extends BaseTest {
    @Test (priority = 1)
    public void test2() {
        System.out.println("printing test_2");
    }

    @Test(priority = 3)
    public void test3() {
        System.out.println("printing test_3");
    }
}

Test2:

public class Test2 extends BaseTest {
    @Test(priority = 1)
    public void test4() {
        System.out.println("printing test_4");
    }

    @Test (priority = 3)
    public void test5() {
        System.out.println("printing test_5");
    }
}

Output:

printing Before Class Method
printing test_2
printing test_3
printing Before Class Method
printing test_4
printing test_5
===============================================
Menu
Total tests run: 4, Passes: 4, Failures: 0, Skips: 0
===============================================

JUnit BeforeAll vs static block - order of execution

The order is determined by Java classloading and JUnit5's TestEngine [1] (If I'm correct). So there's a difference between JUnit's test execution and Java's class loading.

@BeforeAll vs static block

Remember difference between these two.

static blocks - are executed only once when Java's classloader loads the class in memory e.g. creating a first class instance.

@BeforeAll - methods are executed by JUnit's test engine before all tests in the current test class.

So if you would have another test class extending Base and run all tests, static block will be executed only once, whereas @BeforeAll twice (per each test class).

Explanation of order

1. When JUnit executes the tests it instantiate your Child, which first needs to call a Base.
2. "A" - Java classloader has not loaded Base class yet, so it loads the class and - calls the static block.
3. "B" - JUnit's runner sees @BeforeAll annotation and checks wheter it has been called already and if not it calls the method.
4. "C" - Now Java can finish instatiation of Child so classloader can load it and calls the static block.
5. "D" - Child is initialized and method annotated by @Test is executed.

Now imagine there's another class e.g. AnotherChild extending Base. We are executing two test classes Child and AnotherChild, so JUnit has to call @BeforeAll twice, but Java already loaded Base class during execution of the first test class, so it will be called only once.

Note, that this is roughly simplified situation and in reality it's a bit complicated (as usual).

---

[1] https://junit.org/junit5/docs/current/api/org.junit.platform.engine/org/junit/platform/engine/TestEngine.html

---

Related Topics