java.lang.NoSuchMethodError: org.testng.Assert.assertTrue

[hollywood]

I'm receiving the following error below when I try to use
assertTrue(boolean,String)

If I use assertTrue(boolean) it will work. Any idea what the issue
is?

java.lang.NoSuchMethodError: org.testng.Assert.assertTrue(ZLjava/lang/
String;)V

[hollywood]

Forgot to mention that I was using eclipse 3.6

I reverted back to 3.5.2 and the solved the problem.

Is anyone else able to reproduce this issue?

[hollywood]

it ended up being the plugin version I was using.

I downgraded by testng plugin to org.testng.eclipse_5.12.0.6.jar on
eclipse 3.6 and that resolved the issue.

The latest version is: org.testng.eclipse_5.14.1.2

[Tomás Pollak]

The problem is that the test.jar used for compilation is from a different version than the one that the plugin uses to run the tests.

The change was made here:
http://github.com/cbeust/testng/commit/d50ccac164dae9b0d657c359aeae90cc9d338880
and then reverted here:
http://github.com/cbeust/testng/commit/49bffd72afdde5c803ed766cfa45ba50dccfd185

Cedric, the problem of version compatibility is a tough one. Several approaches are possible:
1) Maintain backwards compatibility at all cost, like in this case, revert the commit or overload the API methods. This means that testNG's public API will be more difficult to evolve (in this case based on user feedback).
2) Does it make sense to compile the tests with one version and run them with another? If I'm not mistaken ANT and Maven pick up the jar from the classpath. However the Eclipse plugin comes bundled with a jar and that one is used, hence the discrepancy with the compilation. This means enhancing the Eclipse plugin, I'm not sure if that's difficult.
3) Add a check on the Eclipse plugin to enforce or warn for a minimum version in the project's build path. This will enforce API compatibility but sometimes the developers cannot choose the testNG version to use (corporate policies, etc).

The public API comprises the asserts, annotations and hookable interfaces. This problem may arise again in the future.
Cedric, what's your opinion? How far should TestNG go to maintain backwards compatibility?

Cheers,
Tomás

--
You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to testng...@googlegroups.com.
To unsubscribe from this group, send email to testng-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en.

[Cédric Beust ♔]

Hi Tomás,

This hasn't been a huge problem so far. Once in a while, there is a corner case that happens (such as this one, after all, replacing a String with a CharSequence should always be backward compatible, right? Well, no) but overall, it hasn't been too bad.

This is why the Eclipse plug-in embeds its own testng.jar file, which helps minimize this problem (but doesn't eliminate it entirely, see the recent problems when m2eclipse comes into the picture).

My overall approach is to *never* break backward compatibility, or at least not intentionally. There is just too much TestNG code out there for this to ever be an option.

It doesn't really hamper evolution but it does occasionally create ugly interfaces. Still, it's always possible to introduce brand new API's and remove doc references to the old one.

-- 

Cédric

--
Cédric