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

Suite configuration is not applied to tests selected by unique ID #3693

Closed
Tracked by #3838
mpkorstanje opened this issue Feb 16, 2024 · 1 comment · Fixed by #3694
Closed
Tracked by #3838

Suite configuration is not applied to tests selected by unique ID #3693

mpkorstanje opened this issue Feb 16, 2024 · 1 comment · Fixed by #3694

Comments

@mpkorstanje
Copy link
Contributor

mpkorstanje commented Feb 16, 2024

Steps to reproduce

Given a suite with some configuration:

@Suite
@ConfigurationParameter(key = Constants.DEFAULT_TEST_INSTANCE_LIFECYCLE_PROPERTY_NAME, value = "per_class")
@SelectClasses(ExampleTest.class)
public class SuiteTest {
}

And a test that is sensitive to that configuration

class ExampleTest {

    boolean shared = false;

    @Test
    void test1(){
        if(!shared) {
            System.out.println("Hello world 1");
        } else {
            System.out.println("World was already greeted");
        }
        shared = true;

    }

    @Test
    void test2(){
        if(!shared) {
            System.out.println("Hello world 2");
        } else {
            System.out.println("World was already greeted");
        }
        shared = true;
    }
}

Then executing the tests either by their uniqueId or the SuiteTest class should not make a difference in execution:

public class TestRunner {

    public static void main(String[] args) {
        System.out.println("By suite");

        LauncherDiscoveryRequest requestA = request()
                .selectors(
                        DiscoverySelectors.selectClass(SuiteTest.class)
                )
                .build();

        LauncherFactory.create().execute(requestA);

        System.out.println("By unique id");

        LauncherDiscoveryRequest requestB = request()
                .selectors(
                        DiscoverySelectors.selectUniqueId(
                                UniqueId.forEngine("junit-platform-suite")
                                        .append("suite", "com.example.SuiteTest")
                                        .appendEngine("junit-jupiter")
                                        .append("class", "com.example.ExampleTest" )
                                        .append("method", "test1()")
                        ),
                        DiscoverySelectors.selectUniqueId(
                                UniqueId.forEngine("junit-platform-suite")
                                        .append("suite", "com.example.SuiteTest")
                                        .appendEngine("junit-jupiter")
                                        .append("class", "com.example.ExampleTest" )
                                        .append("method", "test2()")
                        )
                )
                .build();

        LauncherFactory.create().execute(requestB);
    }
}

But when executed we see that this is the case.

By suite
Hello world 1
World was already greeted

By unique id
Hello world 1
Hello world 2

Context

  • JUnit 5.10.1.

The above example is somewhat contrived for the sake of reproducibility. The actual problems showed up when using Surefire to rerun Cucumber tests in a Suite. Surefire uses unique ids to rerun failures and Cucumber Suites tend to come with more configuration than JUnit.

@mpkorstanje mpkorstanje changed the title Tests in a suite, executed by id, do not include a suites configuration Tests in a suite, executed by id, do not use suite configuration Feb 16, 2024
@mpkorstanje mpkorstanje changed the title Tests in a suite, executed by id, do not use suite configuration Tests in a suite, executed by id, do not use configuration Feb 16, 2024
mpkorstanje added a commit to mpkorstanje/junit5 that referenced this issue Feb 16, 2024
@sbrannen sbrannen changed the title Tests in a suite, executed by id, do not use configuration Tests in a suite, selected by unique ID, do not use suite configuration Feb 17, 2024
@sbrannen sbrannen added this to the 5.11 M1 milestone Feb 17, 2024
@sbrannen sbrannen changed the title Tests in a suite, selected by unique ID, do not use suite configuration Suite configuration is not applied to tests in a suite when selected by unique ID Feb 17, 2024
@sbrannen
Copy link
Member

Thanks for bringing this to our attention and for providing a detailed example.

I've confirmed that this is a bug, and I've assigned it to the 5.11 M1 milestone.

We don't currently have any plans to release 5.10.3; however, if more bugs accumulate we may choose to backport the fix for this to 5.10.x as well.

@sbrannen sbrannen changed the title Suite configuration is not applied to tests in a suite when selected by unique ID Suite configuration is not applied to tests when selected by unique ID Feb 17, 2024
@sbrannen sbrannen changed the title Suite configuration is not applied to tests when selected by unique ID Suite configuration is not applied to tests selected by unique ID Feb 18, 2024
marcphilipp pushed a commit that referenced this issue Mar 19, 2024
Tests in a suite selected by unique id did not receive their
configuration because this was only applied to the discovery request
builder when a suite class was selected. By splitting the processing of
configuration annotations and select and filter annotations, the
configuration can now always be applied prior to discovery.

Fixes #3693.
sbrannen added a commit that referenced this issue Mar 21, 2024
@marcphilipp marcphilipp modified the milestones: 5.11 M1, 5.10.3 Jun 17, 2024
marcphilipp pushed a commit that referenced this issue Jun 17, 2024
Tests in a suite selected by unique id did not receive their
configuration because this was only applied to the discovery request
builder when a suite class was selected. By splitting the processing of
configuration annotations and select and filter annotations, the
configuration can now always be applied prior to discovery.

Fixes #3693.

(cherry picked from commit 74bd85c)
marcphilipp pushed a commit that referenced this issue Jun 17, 2024
See #3693

(cherry picked from commit 2a5c6b2)
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.

3 participants