Resource locking with @ResourceLock in JUnit

Introduction

Resource locking helps tests avoid conflicts when they use the same resource at the same time. It makes tests run safely without breaking each other.

When multiple tests access the same file and might change it.

When tests share a database and could interfere with each other's data.

When tests use a shared network connection or port.

When tests modify global settings or environment variables.

When running tests in parallel that use the same hardware device.

Syntax

JUnit

@ResourceLock(value = "resourceName", mode = ResourceAccessMode.READ) or @ResourceLock(value = "resourceName", mode = ResourceAccessMode.WRITE)

Use value to name the shared resource.

Use mode to specify if the test reads or writes the resource.

Examples

This locks the "database" resource for writing, so no other test can read or write it at the same time.

JUnit

@ResourceLock(value = "database", mode = ResourceAccessMode.WRITE)
void testUpdateDatabase() { ... }

This locks the "configFile" resource for reading, allowing multiple reads but no writes during the test.

JUnit

@ResourceLock(value = "configFile", mode = ResourceAccessMode.READ)
void testReadConfig() { ... }

Sample Program

This example shows two tests using the same resource "sharedFile". One test locks it for writing, the other for reading. JUnit will run them safely so they don't conflict.

JUnit

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.parallel.ResourceLock;
import org.junit.jupiter.api.parallel.ResourceAccessMode;

public class ResourceLockExample {

    @Test
    @ResourceLock(value = "sharedFile", mode = ResourceAccessMode.WRITE)
    void testWriteToFile() {
        System.out.println("Writing to shared file");
        // simulate writing
    }

    @Test
    @ResourceLock(value = "sharedFile", mode = ResourceAccessMode.READ)
    void testReadFromFile() {
        System.out.println("Reading from shared file");
        // simulate reading
    }
}

Important Notes

Use WRITE mode when the test changes the resource.

Use READ mode when the test only reads the resource.

Tests with WRITE lock block other tests with READ or WRITE locks on the same resource.

Summary

@ResourceLock prevents tests from interfering when sharing resources.

Use resource names and access modes to control test access.

This helps tests run safely in parallel without errors.

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