@Execution annotation in JUnit

Introduction

The @Execution annotation tells JUnit how to run tests: either all at once or one by one. This helps control test speed and resource use.

When you want tests to run in parallel to finish faster.

When tests share data and must run one after another to avoid conflicts.

When debugging a test that fails only if run with others.

When running many tests and you want to speed up the process.

Syntax

JUnit

@Execution(ExecutionMode.CONCURRENT)
// or
@Execution(ExecutionMode.SAME_THREAD)

@Execution is placed on a test class or test method.

ExecutionMode.CONCURRENT runs tests in parallel.

ExecutionMode.SAME_THREAD runs tests one by one.

Examples

This runs testOne and testTwo at the same time.

JUnit

@Execution(ExecutionMode.CONCURRENT)
public class MyTests {
    @Test
    void testOne() {}
    @Test
    void testTwo() {}
}

This runs testOne and testTwo one after another.

JUnit

@Execution(ExecutionMode.SAME_THREAD)
public class MyTests {
    @Test
    void testOne() {}
    @Test
    void testTwo() {}
}

Sample Program

This test class runs testA and testB at the same time. Both print start and end messages with a half-second pause.

JUnit

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.parallel.Execution;
import org.junit.jupiter.api.parallel.ExecutionMode;

@Execution(ExecutionMode.CONCURRENT)
public class SampleExecutionTest {

    @Test
    void testA() throws InterruptedException {
        System.out.println("Start testA");
        Thread.sleep(500);
        System.out.println("End testA");
    }

    @Test
    void testB() throws InterruptedException {
        System.out.println("Start testB");
        Thread.sleep(500);
        System.out.println("End testB");
    }
}

Important Notes

Parallel tests can speed up testing but may cause issues if tests share data.

Use @Execution carefully to avoid flaky tests.

Summary

@Execution controls if tests run together or one by one.

Use ExecutionMode.CONCURRENT for faster parallel tests.

Use ExecutionMode.SAME_THREAD to avoid conflicts in shared data.

Practice

1. What is the main purpose of the @Execution annotation in JUnit?

easy

A. To set the timeout for a test

B. To specify the order of test execution

C. To mark a test as disabled

D. To control whether tests run concurrently or sequentially

Solution

1. Step 1: Understand the role of @Execution

   The @Execution annotation controls how tests are run: either all at once (concurrently) or one after another (sequentially).

2. Step 2: Differentiate from other annotations

   It does not set order, disable tests, or set timeouts. Those are handled by other annotations like @Order, @Disabled, or @Timeout.

3. Final Answer:

   To control whether tests run concurrently or sequentially -> Option D

4. Quick Check:

   @Execution controls test concurrency = A [OK]

Hint: Remember: @Execution decides parallel or one-by-one run [OK]

Common Mistakes:

• Confusing @Execution with @Order
• Thinking it disables tests
• Assuming it sets test timeouts

2. Which of the following is the correct syntax to run tests concurrently using @Execution in JUnit?

easy

A. @Execution(ExecutionMode.CONCURRENT)

B. @Execution(ExecutionMode.SAME_THREAD)

C. @Execution(ExecutionMode.SEQUENTIAL)

D. @Execution(ExecutionMode.PARALLEL)

Solution

1. Step 1: Recall valid ExecutionMode values

   JUnit defines ExecutionMode.CONCURRENT and ExecutionMode.SAME_THREAD. There is no SEQUENTIAL or PARALLEL mode.

2. Step 2: Identify the mode for concurrent execution

   ExecutionMode.CONCURRENT runs tests in parallel threads.

3. Final Answer:

   @Execution(ExecutionMode.CONCURRENT) -> Option A

4. Quick Check:

   Concurrent mode = CONCURRENT [OK]

Hint: Use ExecutionMode.CONCURRENT for parallel tests [OK]

Common Mistakes:

• Using non-existent ExecutionMode values
• Confusing SAME_THREAD with concurrent
• Misspelling ExecutionMode constants

3. Given the following test class, what will be the order of test execution?

@Execution(ExecutionMode.CONCURRENT)
class SampleTest {
  @Test void testA() { System.out.println("A"); }
  @Test void testB() { System.out.println("B"); }
  @Test void testC() { System.out.println("C"); }
}

medium

A. Tests run one by one in order: A, B, C

B. Tests run concurrently; order of output is unpredictable

C. Tests run concurrently but always print in alphabetical order

D. Tests run sequentially but in reverse order: C, B, A

Solution

1. Step 1: Understand ExecutionMode.CONCURRENT effect

   With @Execution(ExecutionMode.CONCURRENT), tests run in parallel threads, so their output order is not guaranteed.

2. Step 2: Analyze output behavior

   Since threads run independently, print statements may appear in any order depending on thread scheduling.

3. Final Answer:

   Tests run concurrently; order of output is unpredictable -> Option B

4. Quick Check:

   Concurrent = unpredictable order [OK]

Hint: Concurrent tests print in any order, not fixed [OK]

Common Mistakes:

• Assuming concurrent means ordered
• Thinking output is alphabetical
• Confusing concurrent with sequential execution

4. Identify the error in this JUnit test class using @Execution:

@Execution(ExecutionMode.CONCURRENT)
class TestExample {
  private int counter = 0;

  @Test
  void increment() {
    counter++;
    assertEquals(1, counter);
  }

  @Test
  void decrement() {
    counter--;
    assertEquals(-1, counter);
  }
}

medium

A. Shared mutable state causes race conditions in concurrent tests

B. Missing @BeforeEach to reset counter before each test

C. No error; tests run correctly in concurrent mode

D. Incorrect use of @Execution; should be @Order

Solution

1. Step 1: Analyze shared state usage

   The counter variable is shared and modified by both tests without synchronization.

2. Step 2: Understand concurrency impact

   Running tests concurrently causes race conditions, leading to unpredictable counter values and test failures.

3. Final Answer:

   Shared mutable state causes race conditions in concurrent tests -> Option A

4. Quick Check:

   Concurrent tests + shared state = race condition [OK]

Hint: Avoid shared mutable state in concurrent tests [OK]

Common Mistakes:

• Ignoring thread safety in concurrent tests
• Assuming tests run sequentially by default
• Confusing @Execution with @Order annotation

5. You have a test suite with some tests that modify shared data and others that do not. How can you use @Execution to optimize test speed while avoiding conflicts?

hard

A. Remove @Execution annotations and rely on default sequential execution

B. Annotate all tests with @Execution(ExecutionMode.CONCURRENT) to run all in parallel

C. Annotate tests that modify shared data with @Execution(ExecutionMode.SAME_THREAD) and others with CONCURRENT

D. Use @Execution(ExecutionMode.SAME_THREAD) on all tests to avoid conflicts

Solution

1. Step 1: Identify tests with shared data modification

   Tests that modify shared data must run sequentially to avoid conflicts.

2. Step 2: Apply @Execution selectively

   Use @Execution(ExecutionMode.SAME_THREAD) on tests with shared data, and CONCURRENT on others to speed up execution.

3. Final Answer:

   Annotate tests that modify shared data with @Execution(ExecutionMode.SAME_THREAD) and others with CONCURRENT -> Option C

4. Quick Check:

   Mix SAME_THREAD for shared data, CONCURRENT for others [OK]

Hint: Use SAME_THREAD for shared data tests, CONCURRENT for safe ones [OK]

Common Mistakes:

• Running all tests concurrently ignoring shared data
• Running all tests sequentially losing speed benefits
• Not using @Execution selectively per test