@Execution annotation in JUnit - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Purpose of @Execution annotation in JUnit

What is the primary purpose of the @Execution annotation in JUnit 5?

A To provide a timeout value for test execution

B To define the order in which test methods are executed

C To mark a test method as disabled temporarily

D To specify whether tests in a class or method should run concurrently or sequentially

💡 Hint

Think about controlling how tests run in parallel or not.

The @Execution annotation controls whether tests run concurrently or sequentially. It helps manage parallel execution behavior in JUnit 5.

❓ Predict Output

intermediate

Output of test execution mode with @Execution

Given the following JUnit 5 test class, what is the expected execution mode of the tests?

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 SampleTest {

    @Test
    void testOne() throws InterruptedException {
        Thread.sleep(100);
        System.out.println("Test One");
    }

    @Test
    void testTwo() throws InterruptedException {
        Thread.sleep(100);
        System.out.println("Test Two");
    }
}

A Tests run concurrently, possibly overlapping in time

B Tests run in random order but sequentially

C Tests run sequentially, one after another

D Tests are skipped due to incorrect annotation usage

💡 Hint

Look at the ExecutionMode value used in the annotation.

The annotation @Execution(ExecutionMode.CONCURRENT) instructs JUnit to run tests concurrently, so the two tests may overlap in execution time.

❓ assertion

advanced

Correct assertion for verifying parallel execution

Which assertion best verifies that two test methods annotated with @Execution(ExecutionMode.CONCURRENT) actually ran in parallel?

A assertEquals(testOneStartTime, testTwoStartTime) // tests started at exactly the same time

B assertTrue(testOneEndTime - testTwoStartTime < 0) // testOne ended before testTwo started

C assertTrue(Math.abs(testOneEndTime - testTwoEndTime) < expectedOverlap) // tests overlapped in time

D assertFalse(testOneEndTime > testTwoStartTime) // testOne ended after testTwo started

💡 Hint

Parallel tests overlap in execution time, so their end times should be close.

To verify parallel execution, you check if the tests overlapped in time. Option C checks if the difference between their end times is less than an expected overlap threshold.

🔧 Debug

advanced

Why does @Execution annotation have no effect?

A developer added @Execution(ExecutionMode.CONCURRENT) to a test class, but tests still run sequentially. What is the most likely reason?

A The annotation is misspelled and ignored by JUnit

B The test runner does not support parallel execution or it is not enabled

C The tests have @Disabled annotation which forces sequential execution

D JUnit 5 does not support the @Execution annotation

💡 Hint

Check if parallel execution is enabled in the test environment.

Even if @Execution(ExecutionMode.CONCURRENT) is present, parallel execution must be enabled in the JUnit platform configuration or test runner. Otherwise, tests run sequentially.

❓ framework

expert

Combining @Execution with other parallel annotations

In JUnit 5, if a test class is annotated with @Execution(ExecutionMode.CONCURRENT) and individual test methods are annotated with @Execution(ExecutionMode.SAME_THREAD), what is the effective execution mode for those methods?

A Method-level SAME_THREAD overrides class-level CONCURRENT; those methods run sequentially

B Methods annotated with SAME_THREAD run sequentially; others run concurrently

C Class-level CONCURRENT overrides method-level SAME_THREAD; all run concurrently

D JUnit throws a runtime error due to conflicting annotations

💡 Hint

Method-level annotations override class-level annotations in JUnit.

In JUnit 5, method-level @Execution annotations override class-level ones. So methods with SAME_THREAD run sequentially even if the class is marked CONCURRENT.

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