Resource locking with @ResourceLock in JUnit - Test Execution Trace

Test Overview

This test demonstrates how to use @ResourceLock in JUnit to prevent concurrent access to a shared resource. It verifies that two test methods do not run at the same time on the same resource, avoiding conflicts.

Test Code

JUnit

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.parallel.ResourceLock;
import org.junit.jupiter.api.parallel.Resources;
import static org.junit.jupiter.api.Assertions.assertTrue;

public class ResourceLockTest {

    private static int sharedCounter = 0;

    @Test
    @ResourceLock(value = Resources.SYSTEM_PROPERTIES, mode = ResourceLock.Mode.READ)
    void testReadLock() throws InterruptedException {
        int before = sharedCounter;
        Thread.sleep(100); // Simulate read operation
        int after = sharedCounter;
        assertTrue(before == after, "Shared counter should not change during read lock");
    }

    @Test
    @ResourceLock(value = Resources.SYSTEM_PROPERTIES, mode = ResourceLock.Mode.WRITE)
    void testWriteLock() throws InterruptedException {
        int before = sharedCounter;
        sharedCounter++;
        Thread.sleep(100); // Simulate write operation
        int after = sharedCounter;
        assertTrue(after == before + 1, "Shared counter should increment by 1 during write lock");
    }
}

Execution Trace - 10 Steps

Step	Action	System State	Assertion	Result
1	Test runner starts and prepares to run testReadLock	No tests running, sharedCounter = 0	—	PASS
2	testReadLock acquires READ lock on SYSTEM_PROPERTIES resource	Lock acquired, testReadLock running	—	PASS
3	testReadLock reads sharedCounter value (0), sleeps 100ms simulating read	sharedCounter = 0, testReadLock active	—	PASS
4	testReadLock asserts sharedCounter unchanged during read lock	sharedCounter still 0	assertTrue(before == after)	PASS
5	testReadLock releases READ lock	No locks held	—	PASS
6	Test runner starts testWriteLock	No tests running, sharedCounter = 0	—	PASS
7	testWriteLock acquires WRITE lock on SYSTEM_PROPERTIES resource	Lock acquired, testWriteLock running	—	PASS
8	testWriteLock reads sharedCounter (0), increments it to 1, sleeps 100ms simulating write	sharedCounter = 1, testWriteLock active	—	PASS
9	testWriteLock asserts sharedCounter incremented by 1 during write lock	sharedCounter = 1	assertTrue(after == before + 1)	PASS
10	testWriteLock releases WRITE lock	No locks held	—	PASS

Failure Scenario

Failing Condition: If the resource lock is not respected and both tests run concurrently, sharedCounter may change unexpectedly during read lock.

Execution Trace Quiz - 3 Questions

What does @ResourceLock prevent in these tests?

A Assertions from failing

B Tests from running at all

C Concurrent access to the same resource

D The sharedCounter from incrementing

Key Result

Using @ResourceLock in JUnit helps avoid race conditions by controlling access to shared resources during parallel test execution.

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