@Execution annotation in JUnit - Cheat Sheet & Quick Revision

Recall & Review

beginner

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

The <code>@Execution</code> annotation controls whether tests in a test class or method run concurrently or sequentially in JUnit.

beginner

What are the two modes available with the @Execution annotation?

The two modes are CONCURRENT (tests run in parallel) and SAME_THREAD (tests run sequentially in the same thread).

beginner

How do you apply <code>@Execution</code> to run all tests in a class concurrently?

Add <code>@Execution(ExecutionMode.CONCURRENT)</code> above the test class declaration to run all its tests in parallel.

intermediate

Can @Execution be used on individual test methods?

No, <code>@Execution</code> is only applicable at the class level to control execution mode for all tests in that class.

intermediate

Why might you choose ExecutionMode.SAME_THREAD over CONCURRENT?

Use SAME_THREAD when tests share state or resources that are not thread-safe, to avoid flaky or failing tests.

What does @Execution(ExecutionMode.CONCURRENT) do in JUnit?

A Skips the tests

B Runs tests one after another in the same thread

C Runs tests only once

D Runs tests in parallel threads

The CONCURRENT mode runs tests in parallel threads to speed up execution.

Where can you apply the @Execution annotation?

A On both test classes and methods

B On individual test methods only

C On test classes only

D On test suites only

@Execution is designed to be used on test classes to control execution mode for all tests inside.

Which execution mode should you use if your tests share mutable state?

A SAME_THREAD

B CONCURRENT

C PARALLEL

D ASYNC

SAME_THREAD ensures tests run sequentially to avoid conflicts with shared mutable state.

What is the default execution mode if @Execution is not specified?

A CONCURRENT

B SAME_THREAD

C ASYNC

D PARALLEL

JUnit runs tests sequentially by default, which corresponds to SAME_THREAD mode.

Which import is required to use @Execution in JUnit?

A org.junit.jupiter.api.parallel.Execution

B org.junit.jupiter.api.Test

C org.junit.jupiter.api.BeforeEach

D org.junit.jupiter.api.Assertions

The @Execution annotation is in the org.junit.jupiter.api.parallel package.

Explain how the @Execution annotation affects test execution in JUnit.

Think about running tests at the same time versus one by one.

Describe a scenario where you would prefer ExecutionMode.SAME_THREAD over CONCURRENT.

Consider tests that might interfere with each other if run at the same time.

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