Why @Execution annotation in JUnit? - Purpose & Use Cases

The Big Idea

What if you could speed up your tests with just one simple annotation?

The Scenario

Imagine you have many test cases to run, but you want to control if they run one after another or all at once. Doing this by hand means running tests one by one or opening many windows to run them all, which is confusing and slow.

The Problem

Manually managing test execution order or parallelism is slow and error-prone. You might forget to run some tests, or tests might interfere with each other if run at the same time. It's hard to keep track and wastes time.

The Solution

The @Execution annotation lets you easily tell JUnit how to run your tests: either all in order or in parallel. This saves time and avoids mistakes by automating test execution control.

Before vs After

✗ Before

Run tests one by one manually or open multiple consoles to run tests in parallel.

✓ After

@Execution(ExecutionMode.CONCURRENT)
public class MyTests { ... }

What It Enables

You can run tests faster and more reliably by simply adding @Execution to control parallel or sequential execution.

Real Life Example

When testing a web app, you want to run many UI tests at the same time to save time, but some tests must run in order to avoid conflicts. @Execution helps you set this easily.

Key Takeaways

Manual test running is slow and error-prone.

@Execution controls test run order and parallelism.

This makes testing faster and more reliable.

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