@Execution annotation in JUnit - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to import the correct package for the @Execution annotation.

JUnit

import org.junit.jupiter.api.parallel.[1];

Drag options to blanks, or click blank then click option'

ATest

BBeforeEach

CExecution

DAfterAll

Attempts:

3 left

💡 Hint

Common Mistakes

Importing @Test instead of @Execution

Using annotations from JUnit 4 packages

The @Execution annotation is part of the org.junit.jupiter.api.parallel package in JUnit 5.

2fill in blank

medium

Complete the code to set the execution mode to concurrent using @Execution.

JUnit

@Execution(ExecutionMode.[1])
public class MyTests { }

Drag options to blanks, or click blank then click option'

ACONCURRENT

BSAME_THREAD

CSEQUENTIAL

DPARALLEL

Attempts:

3 left

💡 Hint

Common Mistakes

Using SAME_THREAD which runs tests sequentially

Using non-existent modes like PARALLEL

The ExecutionMode.CONCURRENT tells JUnit to run tests in parallel threads.

3fill in blank

hard

Fix the error in the annotation usage to correctly specify execution mode.

JUnit

@Execution(ExecutionMode.[1])
public class MyTests { }

Drag options to blanks, or click blank then click option'

ASAME_THREAD

Bparallel

Csame_thread

DCONCURRENT

Attempts:

3 left

💡 Hint

Common Mistakes

Using lowercase or snake_case instead of uppercase enum constants

Using invalid enum values

ExecutionMode enum constants must be uppercase and exactly as defined, like CONCURRENT.

4fill in blank

hard

Fill both blanks to import the ExecutionMode enum and use it to run tests in the same thread.

JUnit

import org.junit.jupiter.api.parallel.[1];
@Execution(ExecutionMode.[2])
public class SampleTest { }

Drag options to blanks, or click blank then click option'

AExecutionMode

BCONCURRENT

CSAME_THREAD

DExecution

Attempts:

3 left

💡 Hint

Common Mistakes

Importing Execution instead of ExecutionMode

Using CONCURRENT instead of SAME_THREAD

You must import ExecutionMode enum and use SAME_THREAD to run tests sequentially.

5fill in blank

hard

Fill all three blanks to create a test class that runs tests concurrently and imports both required annotations.

JUnit

import org.junit.jupiter.api.parallel.[1];
import org.junit.jupiter.api.[2];
@Execution(ExecutionMode.[3])
public class ConcurrentTests { }

Drag options to blanks, or click blank then click option'

AExecution

BTest

CCONCURRENT

DBeforeEach

Attempts:

3 left

💡 Hint

Common Mistakes

Forgetting to import @Test annotation

Using wrong execution mode values

Import Execution and Test annotations, then set execution mode to CONCURRENT for parallel tests.

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