Resource locking with @ResourceLock in JUnit - Build an Automation Script

Test resource locking using @ResourceLock annotation in JUnit

Preconditions (2)

Step 1: Create a test class with two test methods

Step 2: Annotate both test methods with @ResourceLock using the same resource name

Step 3: Run the tests in parallel mode

Step 4: Observe that the tests do not run concurrently on the locked resource

✅ Expected Result: The two test methods run sequentially, not in parallel, because the shared resource is locked by @ResourceLock

Automation Requirements - JUnit 5.9+

Assertions Needed:

Verify that both test methods complete successfully

Verify that the resource lock prevents concurrent execution

Best Practices:

Use @ResourceLock with a clear resource name

Enable parallel execution in JUnit configuration

Use assertions to confirm test completion

Avoid hardcoding thread sleeps; rely on JUnit's locking

Automated Solution

JUnit

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

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

@Execution(ExecutionMode.CONCURRENT)
public class ResourceLockTest {

    private static volatile boolean resourceInUse = false;

    @Test
    @ResourceLock("SHARED_RESOURCE")
    void testMethodOne() throws InterruptedException {
        assertTrue(acquireResource());
        // Simulate work with the resource
        Thread.sleep(200);
        releaseResource();
    }

    @Test
    @ResourceLock("SHARED_RESOURCE")
    void testMethodTwo() throws InterruptedException {
        assertTrue(acquireResource());
        // Simulate work with the resource
        Thread.sleep(200);
        releaseResource();
    }

    private synchronized boolean acquireResource() {
        if (resourceInUse) {
            return false; // resource already in use
        }
        resourceInUse = true;
        return true;
    }

    private synchronized void releaseResource() {
        resourceInUse = false;
    }
}

This test class uses @Execution(ExecutionMode.CONCURRENT) to allow parallel test execution.

Both test methods are annotated with @ResourceLock("SHARED_RESOURCE") to lock the same resource name.

The resourceInUse flag simulates the shared resource state. The acquireResource() method ensures only one test can use the resource at a time.

Each test sleeps for 200ms to simulate work, then releases the resource.

Assertions check that the resource was successfully acquired, confirming the lock works.

Because of @ResourceLock, JUnit runs these tests sequentially on the shared resource, preventing concurrent access.

Common Mistakes - 3 Pitfalls

Not enabling parallel execution in JUnit configuration

Using different resource names in @ResourceLock annotations

Using Thread.sleep() without proper synchronization

Bonus Challenge

Now add a third test method that locks a different resource and verify it runs concurrently with the others.

Show Hint

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