Order for DependsOnGroups has changed after TestNg 7.4.0

TestNG Version

7.5 not working 7.4 works

Expected behavior

s3 s1 s2

Actual behavior

s1 s2 s3

Is the issue reproducible on runner?

• Maven
• Eclipse
• IntelliJ

Test case sample

Here is an example for BeforeSuite, but the same problem exists for all configuration methods. The same issue also for dependsOnMethod

    @BeforeSuite(groups = { "g1" })
    public void s3() {
        System.out.println("s3");
    }

    @BeforeSuite(groups = { "g2" }, dependsOnGroups = "g1")
    public void s2() {
        System.out.println("s2");
    }

    @BeforeSuite(groups = { "g2" }, dependsOnGroups = "g1")
    public void s1() {
        System.out.println("s1");
    }

    @Test()
    public void test3() {
        System.out.println("test3");
    }

I have tried to find the commit where the fault was introduced, but my IDE did not like to switch gradle version and I’m new at gradle.

[martinaldrin]

Hi @krmahadevan I agree unit tests are lacking in this area.

But in my opinion it is not unclear, because of.

1. The sorting was working in the same way for groups and methods in earlier versions.
2. The include/exclude working in the same way for groups and methods in earlier versions. up 7.4 broken in 7.5
3. Include/Exclude of methods and groups are specified in a similar way in the suite.
4. Similarity between the annotation makes it easier to use, if you can expect similar behavior.
5. Documentation does not say anything about that groups must be defined in a suite xml.
6. A if statement was added in the generic sorting mechanism that skipped the sorting for some methods.
7. A Behavior was change, will introduce a non backward compatible change that will affect many users.

[martinaldrin]

@juherr I think it works pretty well for everything except for one that was recently implemented after 7.4 release. With my changes I think groups starts to work as it did before

I also believe that current implementation is quite dangerous, adding dependsOnMethod internally could definitely give some strange behavior since it can interfere with users configuration. Adding an internal priority would be much nicer here, since that can never interfere with the user configuration and just make a more soft sorting that users can override easily.

                  if (!equalsEffectiveClass(m1, m2) && !dependencyExists(m1, m2, methods)) {
                    Utils.log("MethodInheritance", 4, m2 + " DEPENDS ON " + m1);
                    m2.addMethodDependedUpon(MethodHelper.calculateMethodCanonicalName(m1));
                  }