search

testng-team / testng

TestNG testing framework
https://testng.org
Apache License 2.0
1.98k stars 1.02k forks source link

DataProvider tests ignored by TestNG 6.9.12 using Gradle 2.14 #1085

Closed ethauvin closed 8 years ago

ethauvin commented 8 years ago

DataProvider tests are ignored by TestNG 6.9.12 using Gradle 2.14 (2.13 and 2.12 too.)

Sample project here using dp sample code from docs.

Switching to 6.9.11 (without any code change) works.

cbeust commented 8 years ago

@juherr I worked with Erik on this one, it's pretty puzzling. Here is what I found so far: the problem seems to be strictly limited to Gradle (I tested 2.14, 2.13, 2.12) and TestNG 6.9.12. TestNG 6.9.11 works fine.

If you build the example project with Gradle, you'll see:

Gradle Test Executor 1 started executing tests.

Gradle suite > Gradle test > LibraryTest.verifyData1 SKIPPED
Gradle Test Executor 1 finished executing tests.

The tests run fine 1) manually (from master with IDEA) and 2) with Kobalt.

juherr commented 8 years ago

Ok, really strange. I think it is something related with my changes on data provider but why is it only happening with gradle...

I think that the next step is to open an issue on the gradle project: https://issues.gradle.org

@ethauvin Could you add maven on your sample project?

ethauvin commented 8 years ago

@juherr Done. DP test is skipped too, so probably not Gradle.

capture

juherr commented 8 years ago

ok, thank!

ethauvin commented 8 years ago

Just noticed the following:

capture

juherr commented 8 years ago

Ok, catched! Good job @ethauvin :+1: I use Guava which is not a direct dependency of TestNG (but a transitive one from Guice which is optional).

@cbeust I see 2 solutions: adding Guava as dependency (it will allow us to use guava) OR rewrite the method I use. Which one do you prefer?

juherr commented 8 years ago

@ethauvin As workarround, you can add guava as dependency of your project. It should work.

ethauvin commented 8 years ago

@juherr It should, I'll play with it tomorrow.

@cbeust Let him use Guava, no need to reinvent the wheel.

cbeust commented 8 years ago

Maybe it's not worth depending on Guava just for that? We have to be very careful what dependencies we bring in with TestNG.

And yes, the bottom line is that you should always declare your direct dependencies in your build file, otherwise you may break in very mysterious ways :-)

juherr commented 8 years ago

Maybe it's not worth depending on Guava just for that? We have to be very careful what dependencies we bring in with TestNG.

No opinion, you choose!

And yes, the bottom line is that you should always declare your direct dependencies in your build file, otherwise you may break in very mysterious ways :-)

For sure, and IDE/buid tools should warn about it when it is not the case (maven has a plugin for that)

cbeust commented 8 years ago

Ok then no Guava :)

Cédric

On Thu, Jul 7, 2016 at 6:11 AM, Julien Herr notifications@github.com wrote:

Maybe it's not worth depending on Guava just for that? We have to be very careful what dependencies we bring in with TestNG.

No opinion, you choose!

And yes, the bottom line is that you should always declare your direct dependencies in your build file, otherwise you may break in very mysterious ways :-)

For sure, and IDE/buid tools should warn about it when it is not the case (maven has a plugin for that)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cbeust/testng/issues/1085#issuecomment-231072840, or mute the thread https://github.com/notifications/unsubscribe/AAFoooOvy1IuFDbl5Y7M1OlNgEF0PClFks5qTPrtgaJpZM4JGeH4 .

ethauvin commented 8 years ago

FYI, as expected, workaround works with Gradle, Kobalt and Maven.

Sample project has been updated.