Resource locking with @ResourceLock in JUnit - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of concurrent tests with @ResourceLock

Consider the following JUnit 5 test class using @ResourceLock to manage concurrent access. What will be the output order of the printed statements when running all tests in parallel?

JUnit

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.parallel.ResourceLock;
import org.junit.jupiter.api.parallel.Resources;
import org.junit.jupiter.api.parallel.Execution;
import org.junit.jupiter.api.parallel.ExecutionMode;

@Execution(ExecutionMode.CONCURRENT)
public class ResourceLockTest {

    @Test
    @ResourceLock(value = "RESOURCE_A")
    void test1() throws InterruptedException {
        System.out.println("Start test1");
        Thread.sleep(100);
        System.out.println("End test1");
    }

    @Test
    @ResourceLock(value = "RESOURCE_A")
    void test2() throws InterruptedException {
        System.out.println("Start test2");
        Thread.sleep(100);
        System.out.println("End test2");
    }

    @Test
    void test3() {
        System.out.println("Start test3");
        System.out.println("End test3");
    }
}

A Start test3\nStart test1\nStart test2\nEnd test3\nEnd test1\nEnd test2

B Start test1\nStart test2\nEnd test1\nEnd test2\nStart test3\nEnd test3

C Start test1\nEnd test1\nStart test2\nEnd test2\nStart test3\nEnd test3

D Start test3\nEnd test3\nStart test1\nEnd test1\nStart test2\nEnd test2

💡 Hint

Remember that tests locking the same resource run sequentially, but tests without locks can run concurrently.

Tests test1 and test2 both lock RESOURCE_A, so they run one after another. test3 has no lock and can run concurrently, so it may start and finish before or during the others. The only guaranteed order is that test1 and test2 do not overlap.

❓ assertion

intermediate

Correct assertion for resource lock count

You have a test method annotated with @ResourceLock("DB_CONNECTION") that increments a shared counter. Which assertion correctly verifies that the counter increments exactly once per test execution when tests run concurrently?

JUnit

import static org.junit.jupiter.api.Assertions.assertEquals;

int counter = 0;

@Test
@ResourceLock("DB_CONNECTION")
void incrementCounter() {
    counter++;
}

A assertEquals(1, counter);

B assertEquals(2, counter);

C assertNotNull(counter);

D assertTrue(counter >= 1);

💡 Hint

The resource lock ensures only one test increments at a time, so the counter should be exactly 1 after one test.

Because the resource lock serializes access, the counter increments once per test execution. The correct assertion checks for exactly 1.

🔧 Debug

advanced

Identify the cause of test deadlock with @ResourceLock

Given two test methods each annotated with @ResourceLock on different resources but run concurrently, the test suite hangs indefinitely. What is the most likely cause?

JUnit

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.parallel.ResourceLock;
import org.junit.jupiter.api.parallel.Execution;
import org.junit.jupiter.api.parallel.ExecutionMode;

@Execution(ExecutionMode.CONCURRENT)
public class DeadlockTest {

    @Test
    @ResourceLock(value = "RESOURCE_1")
    void testA() {
        // locks RESOURCE_1
        // then tries to lock RESOURCE_2 inside
    }

    @Test
    @ResourceLock(value = "RESOURCE_2")
    void testB() {
        // locks RESOURCE_2
        // then tries to lock RESOURCE_1 inside
    }
}

A Incorrect @ResourceLock annotation syntax causing test hang

B JUnit does not support concurrent execution with @ResourceLock

C Circular wait due to nested resource locks causing deadlock

D Tests are not annotated with @Execution(ExecutionMode.SAME_THREAD)

💡 Hint

Think about what happens when two tests wait on each other's locked resources.

Deadlock occurs when testA holds RESOURCE_1 and waits for RESOURCE_2, while testB holds RESOURCE_2 and waits for RESOURCE_1, causing circular wait.

❓ framework

advanced

Behavior of @ResourceLock with multiple resources

What happens when a test method is annotated with @ResourceLock(value = {"RESOURCE_X", "RESOURCE_Y"}) in JUnit 5?

A The test locks RESOURCE_X first, then RESOURCE_Y sequentially during execution

B The test locks both RESOURCE_X and RESOURCE_Y simultaneously before execution

C The test locks only RESOURCE_X and ignores RESOURCE_Y

D The test locks RESOURCE_X and RESOURCE_Y but allows other tests to lock them concurrently

💡 Hint

Consider how @ResourceLock handles multiple resource names in its value array.

Annotating with multiple resources locks all listed resources simultaneously to prevent concurrent access conflicts.

🧠 Conceptual

expert

Effect of @ResourceLock on test execution order and concurrency

In a large test suite with many tests annotated with different @ResourceLock values, how does JUnit 5 determine which tests can run concurrently and which must run sequentially?

A Tests locking the same resource run sequentially; tests locking different resources run concurrently

B All tests run sequentially regardless of resource locks to avoid conflicts

C Tests run concurrently only if they have no @ResourceLock annotation

D JUnit randomly schedules tests ignoring resource locks

💡 Hint

Think about resource locking as a way to prevent simultaneous access to shared resources.

JUnit uses resource locks to serialize tests that share the same resource name, allowing tests with different resource locks to run in parallel safely.

Practice

1. What is the main purpose of using @ResourceLock in JUnit tests?

easy

A. To automatically generate test data

B. To prevent tests from interfering when sharing resources

C. To speed up test execution by skipping some tests

D. To disable tests temporarily

Solution

1. Step 1: Understand the role of @ResourceLock

   @ResourceLock is used to control access to shared resources in tests to avoid conflicts.

2. Step 2: Identify the main purpose

   Its main purpose is to prevent tests from interfering with each other when they share resources.

3. Final Answer:

   To prevent tests from interfering when sharing resources -> Option B

4. Quick Check:

   @ResourceLock prevents interference = C [OK]

Hint: Remember: @ResourceLock controls shared resource access [OK]

Common Mistakes:

• Thinking @ResourceLock speeds up tests
• Confusing @ResourceLock with test disabling
• Assuming it generates test data automatically

2. Which of the following is the correct syntax to lock a resource named "database" for read access using @ResourceLock?

easy

A. @ResourceLock(name = "database", type = READ)

B. @ResourceLock(resource = "database", access = READ)

C. @ResourceLock(value = "database", mode = ResourceAccessMode.READ)

D. @ResourceLock("database", mode = READ)

Solution

1. Step 1: Recall the correct annotation syntax

   The correct syntax uses 'value' for resource name and 'mode' for access mode with enum ResourceAccessMode.

2. Step 2: Match options with correct syntax

   @ResourceLock(value = "database", mode = ResourceAccessMode.READ) matches the correct syntax: @ResourceLock(value = "database", mode = ResourceAccessMode.READ).

3. Final Answer:

   @ResourceLock(value = "database", mode = ResourceAccessMode.READ) -> Option C

4. Quick Check:

   Correct syntax uses value and mode = A [OK]

Hint: Use value=resourceName and mode=ResourceAccessMode.[READ/WRITE] [OK]

Common Mistakes:

• Using wrong attribute names like resource or name
• Not using ResourceAccessMode enum
• Omitting enum prefix for mode

3. Given the following test methods, what will happen when they run in parallel?

@ResourceLock(value = "file", mode = ResourceAccessMode.READ)
void testReadFile() { /* read file */ }

@ResourceLock(value = "file", mode = ResourceAccessMode.WRITE)
void testWriteFile() { /* write file */ }

medium

A. testReadFile and testWriteFile will run sequentially to avoid conflicts

B. Both tests will run simultaneously without any locking

C. testWriteFile will run twice before testReadFile starts

D. Tests will fail due to resource locking conflict

Solution

1. Step 1: Understand resource locking modes

   READ mode allows multiple readers simultaneously, WRITE mode requires exclusive access.

2. Step 2: Analyze parallel execution with conflicting modes

   Since one test locks for READ and the other for WRITE on the same resource, they cannot run at the same time.

3. Final Answer:

   testReadFile and testWriteFile will run sequentially to avoid conflicts -> Option A

4. Quick Check:

   READ + WRITE locks cause sequential run = A [OK]

Hint: READ and WRITE locks on same resource run sequentially [OK]

Common Mistakes:

• Assuming READ and WRITE locks allow parallel runs
• Thinking tests will fail due to locking
• Believing WRITE lock allows multiple writers

4. Identify the error in the following test code using @ResourceLock:

@ResourceLock(value = "cache", mode = "READ")
void testCacheRead() { /* test code */ }

medium

A. The mode value should be an enum, not a string

B. The value attribute should be named resource

C. The method must be static to use @ResourceLock

D. The annotation must be placed on the class, not method

Solution

1. Step 1: Check the mode attribute type

   The mode attribute requires a ResourceAccessMode enum value, not a string.

2. Step 2: Identify the error in the code

   Using "READ" as a string causes a syntax error; it should be ResourceAccessMode.READ.

3. Final Answer:

   The mode value should be an enum, not a string -> Option A

4. Quick Check:

   mode must be enum, not string = B [OK]

Hint: Use ResourceAccessMode.READ, not "READ" string [OK]

Common Mistakes:

• Passing mode as a string instead of enum
• Renaming value attribute incorrectly
• Thinking method must be static

5. You have two test methods:

@ResourceLock(value = "service", mode = ResourceAccessMode.READ)
void testServiceRead() { /* read operation */ }

@ResourceLock(value = "service", mode = ResourceAccessMode.READ)
void testAnotherRead() { /* another read */ }

@ResourceLock(value = "service", mode = ResourceAccessMode.WRITE)
void testServiceWrite() { /* write operation */ }

How will JUnit handle these tests when running in parallel?

hard

A. Tests will fail due to deadlock on resource locking

B. All three tests run in parallel without restrictions

C. Write test runs first, then both read tests run sequentially

D. Both read tests run in parallel; write test runs alone after reads finish

Solution

1. Step 1: Understand read locks behavior

   Multiple tests with READ locks on the same resource can run simultaneously.

2. Step 2: Understand write lock behavior

   WRITE lock requires exclusive access, so it must wait until all READ locks finish.

3. Step 3: Determine execution order

   Both read tests run in parallel; the write test runs alone after reads complete.

4. Final Answer:

   Both read tests run in parallel; write test runs alone after reads finish -> Option D

5. Quick Check:

   Multiple READs parallel, WRITE exclusive = D [OK]

Hint: Multiple READs run together; WRITE waits for exclusivity [OK]

Common Mistakes:

• Assuming WRITE runs before READs
• Thinking all tests run simultaneously
• Believing deadlock occurs automatically