testng: TestNG 7.3.0 breaks AssertJ assumeThat

TestNG Version

7.3.0

Expected behavior

Using AssertJ’s org.assertj.core.api.Assumptions.assumeThat method should produce a org.testng.SkipException, skipping the test.

Actual behavior

The code in Assumptions throws org.junit.AssumptionViolatedException instead. This exception is not supported by TestNG, causing a test failure instead of a skipped test.

This is because TestNG includes JUnit 4.12, which is detected by Assumptions.

Is the issue reproductible on runner?

Shell
Maven
Gradle
Ant
Eclipse
IntelliJ
NetBeans

Test case sample

Gradle: implementation 'org.assertj:assertj-core:3.12.1'

public class FooTest
{
    @Test
    public void test()
    {
        org.assertj.core.api.Assumptions.assumeThat(false).isTrue();
    }
}

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 20 (6 by maintainers)

Most upvoted comments

@juherr @cbeust - The link https://github.com/ota4j-team/opentest4j#projects-already-contacted says TestNG has been contacted regarding this. Are you folks aware of this ?

I don’t recall seeing any mail on this on the TestNG dev users list.

@scordio - Maybe you can create a PR (so the technical work related to moving towards this would be done), but we need to get a confirmation from @cbeust on what the plans are for this.

@juherr - WDYT ?

krmahadevan on Aug 27, 2020

@scordio confirmed. Fails with TestNG 7.3.0 and AssertJ 3.17.0, fixed with 7.3.0 / 3.17.1.

C-Otto on Aug 30, 2020

assertj-core 3.17.1 has been released. TestNG exception now takes precedence over JUnit 4.

@C-Otto could you please try again and let us know?

scordio on Aug 30, 2020

I just checked opentest4j and the project has had a handful of commits over the past two years, so it looks pretty dead. What’s the advantage of supporting it?

I wouldn’t say it’s dead, it’s just there was no need of so much activity.

The main advantage I see is in the handling of the cases mentioned by @juherr:

I think the logic is a bit more complicate:

* junit 4 + testng => maybe testng with the junit feature
* junit 5 + testng => maybe junit5 with https://github.com/testng-team/testng-junit5
* other => current logic

Having the same exception thrown by both TestNG and JUnit would simplify the matrix of all the possible cases that libraries like AssertJ need to handle.

scordio on Aug 27, 2020

TestNG should not expose JUnit classes by default but both TestNG and JUnit classes are available when the JUnit support feature is used.

IMO, It should be fixed in AssertJ first and improve the dependencies of TestNG asap.

juherr on Aug 26, 2020