Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a way to inherit ResourceLocks that allows for more parallel execution of tests #3102

Open
1 task
Squibbles opened this issue Dec 6, 2022 · 2 comments · May be fixed by #3220
Open
1 task

Add a way to inherit ResourceLocks that allows for more parallel execution of tests #3102

Squibbles opened this issue Dec 6, 2022 · 2 comments · May be fixed by #3220

Comments

@Squibbles
Copy link

Squibbles commented Dec 6, 2022

As seen in issue #2038 if a class level resource lock is specified, even if it is only a READ lock it will cause all tests that inherit it to run single threaded if any one of those tests uses a READ_WRITE lock. It was suggested in a comment by @leonard84 that it might be possible to add an annotation that would apply to a descriptor's children but not to the descriptor itself. This kind of functionality would be extremely useful in our project because we have 3000+ tests spread over hundreds of test classes. I would like to apply a READ lock to our commonly used resources in the inheritance chain rather than having to add individual resource locks on each of several thousand tests. However, if I do specify a class level/inherited lock of any kind it makes any class that inherits it run in SAME_THREAD mode if there is any READ_WRITE locks anywhere in the class.

In this below example the first two tests run in parallel and tests 3/4 run individually as expected. But if you uncomment the class level resource lock then all tests run individually. I would like there to be a way to specify that all of these tests have a READ lock on resource2 without having to add the lock individually to each test:

   // @ResourceLock(value = "resource2", mode = READ)
   public class SampleClassLevelLocksTest {

    @Test
    @ResourceLock(value = "resource1", mode = READ)
    void test1() throws InterruptedException {
        Thread.sleep(2000L);
        Assertions.assertTrue(true);
    }

    @Test
    @ResourceLock(value = "resource1", mode = READ)
    void test2() throws InterruptedException {
        Thread.sleep(2000L);
        Assertions.assertTrue(true);
    }

    @Test
    @ResourceLock(value = "resource1", mode = READ_WRITE)
    void test3() throws InterruptedException {
        Thread.sleep(2000L);
        Assertions.assertTrue(true);
    }

    @Test
    @ResourceLock(value = "resource1", mode = READ_WRITE)
    void test4() throws InterruptedException {
        Thread.sleep(2000L);
        Assertions.assertTrue(true);
    }

Deliverables

  • Implement a way to specify resource locks that should be inherited to tests without forcing the tests to run in SAME_THREAD mode if there is a READ_WRITE lock anywhere at the same level
@marcphilipp
Copy link
Member

Team decision: Introduce @ResourceLock(target = SELF | CHILDREN) where target would default to SELF to preserve existing behavior. Using CHILDREN would have the same effect as declaring @ResourceLock on every @Test method of a test class.

@marcphilipp marcphilipp added this to the 5.10.0-M1 milestone Dec 16, 2022
anatolyD added a commit to anatolyD/junit5 that referenced this issue Apr 1, 2023
Defaults to SELF to preserve existing behavior.
Using CHILDREN has the same effect as declaring @ResourceLock on every @test method of a test class.

Issue: junit-team#3102
anatolyD added a commit to anatolyD/junit5 that referenced this issue Apr 1, 2023
Defaults to SELF to preserve existing behavior.
Using CHILDREN has the same effect as declaring @ResourceLock on every @test method of a test class.

Issue: junit-team#3102
anatolyD added a commit to anatolyD/junit5 that referenced this issue Apr 1, 2023
 where the target defaults to `SELF` to preserve existing behavior.
 Using `CHILDREN` has the same effect as declaring @ResourceLock
 on every @test method of a test class.

Issue: junit-team#3102
anatolyD added a commit to anatolyD/junit5 that referenced this issue Apr 1, 2023
Using CHILDREN has the same effect as declaring @ResourceLock on every @test method of a test class.

Issue: junit-team#3102
anatolyD added a commit to anatolyD/junit5 that referenced this issue Apr 1, 2023
Using CHILDREN has the same effect as declaring @ResourceLock on every @test method of a test class.

Issue: junit-team#3102
anatolyD added a commit to anatolyD/junit5 that referenced this issue Apr 1, 2023
Defaults to SELF to preserve existing behavior.
Using CHILDREN has the same effect as declaring @ResourceLock on every @test method of a test class.

Issue: junit-team#3102
@anatolyD anatolyD linked a pull request Apr 1, 2023 that will close this issue
7 tasks
@anatolyD
Copy link

anatolyD commented Apr 4, 2023

Hey @Squibbles, can you build locally the branch from PR #3220 to see if that brings any improvement? I soon realized my unit tests work insignificantly better (not that many of those I have to show some real boost)

@marcphilipp I would appreciate your feedback too.

@marcphilipp marcphilipp linked a pull request Apr 20, 2023 that will close this issue
7 tasks
@marcphilipp marcphilipp modified the milestones: 5.10.0-M1, 5.10.0-RC1 Apr 28, 2023
@marcphilipp marcphilipp modified the milestones: 5.10 RC1, 5.11 M1 Jun 16, 2023
@marcphilipp marcphilipp modified the milestones: 5.11 M1, 5.12 Feb 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants