Resource locking with @ResourceLock in JUnit - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is the purpose of the @ResourceLock annotation in JUnit?

The @ResourceLock annotation is used to control access to shared resources during parallel test execution, preventing conflicts by locking resources.

beginner

How do you specify the resource to lock using @ResourceLock?

You specify the resource by setting the value attribute to a string that identifies the resource, for example, @ResourceLock("DATABASE").

intermediate

What are the two modes of locking available in @ResourceLock?

The two modes are READ and WRITE. READ allows multiple tests to access the resource concurrently, WRITE allows exclusive access.

beginner

Why is resource locking important in parallel test execution?

Resource locking prevents tests from interfering with each other when they share resources, ensuring test reliability and avoiding flaky failures.

intermediate

Show a simple example of using @ResourceLock to lock a resource named "FILE" in WRITE mode.

Example:

@ResourceLock(value = "FILE", mode = ResourceAccessMode.WRITE)
void testMethod() {
  // test code that needs exclusive access to FILE
}

What does @ResourceLock("DB") do in a JUnit test?

A Runs the test only if the 'DB' resource is available

B Unlocks the resource named 'DB' after test execution

C Locks the resource named 'DB' to prevent concurrent access

D Marks the test as dependent on the 'DB' resource

@ResourceLock("DB") locks the resource named 'DB' to prevent other tests from accessing it concurrently, ensuring safe parallel execution.

Which ResourceAccessMode allows multiple tests to read the same resource simultaneously?

A READ

B EXCLUSIVE

C WRITE

D SHARED

The READ mode allows multiple tests to access the resource concurrently for reading.

If two tests lock the same resource in WRITE mode, what happens?

A One test waits until the other finishes

B Both tests run at the same time

C Tests fail due to conflict

D Tests run in random order

WRITE mode locks are exclusive, so one test waits for the other to finish before running.

Which annotation is used to lock resources in JUnit 5 for parallel tests?

A @LockResource

B @ResourceLock

C @Synchronized

D @TestLock

The correct annotation is @ResourceLock.

Why should you use resource locking in tests that run in parallel?

A To speed up test execution

B To run tests sequentially

C To skip tests that use shared resources

D To avoid resource conflicts and flaky tests

Resource locking avoids conflicts on shared resources, preventing flaky test failures.

Explain how @ResourceLock helps manage shared resources in parallel JUnit tests.

Think about how tests can interfere with each other when sharing files or databases.

Describe the difference between READ and WRITE modes in @ResourceLock.

Consider how reading and writing to a shared file differ.

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