@Execution annotation in JUnit - Framework Patterns

Framework Mode - @Execution annotation

Folder Structure for JUnit Test Framework

src/
├── main/
│   └── java/
│       └── com/example/app/       # Application source code
└── test/
    └── java/
        └── com/example/app/tests/ # Test classes
            ├── pages/              # Page Object classes
            ├── utils/              # Utility classes (e.g., waits, helpers)
            ├── config/             # Test configuration classes
            └── tests/              # Test classes using @Execution

Test Framework Layers

• Driver Layer: Manages WebDriver setup and teardown for browser automation.
• Page Objects: Encapsulate UI elements and actions for each page.
• Test Classes: Contain test methods annotated with JUnit annotations including @Execution to control parallel or sequential execution.
• Utilities: Helper methods for waits, assertions, and common actions.
• Configuration: Manage environment variables, browser settings, and credentials.

Configuration Patterns

• Environment Profiles: Use Java system properties or config files (e.g., application.properties) to switch between test environments.
• Browser Settings: Parameterize browser type and version via system properties or config classes.
• Credentials Management: Store sensitive data securely outside source code, inject via environment variables or encrypted files.
• JUnit Configuration: Use @Execution annotation at class or method level to specify parallel or sequential execution mode.

Test Reporting and CI/CD Integration

• Integrate JUnit reports with CI tools like Jenkins or GitHub Actions for automated test runs.
• Use plugins (e.g., Surefire, Allure) to generate readable HTML reports showing test results and execution order.
• Configure CI pipelines to run tests in parallel or sequentially based on @Execution annotation settings.
• Fail fast or retry strategies can be configured in CI based on test outcomes.

Best Practices for Using @Execution Annotation

1. Use @Execution(ExecutionMode.CONCURRENT) to speed up test suites by running tests in parallel when tests are independent.
2. Use @Execution(ExecutionMode.SAME_THREAD) for tests that share state or require sequential execution to avoid flaky results.
3. Apply @Execution at the class level to control all tests in that class or at method level for fine-grained control.
4. Ensure thread safety in tests and page objects when running in parallel to prevent race conditions.
5. Combine @Execution with proper setup and teardown methods to isolate tests.

Self Check Question

Where in this folder structure would you add a new test class that uses @Execution(ExecutionMode.CONCURRENT) to run tests in parallel?

Key Result

Use @Execution annotation in JUnit tests to control parallel or sequential execution for efficient and reliable test runs.

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