My inclination would be towards just an error that says its not
supported under TestNG.
I don't know why people even use it with JUnit, except when they have
memory leaks in their tests, or tests that affect the state of the JVM
that they don't tear down :)
- Brett
On 07/02/2008, at 9:59 AM, Dan Fabulich wrote:
Benjamin Bentmann has filed bug SUREFIRE-446
http://jira.codehaus.org/browse/SUREFIRE-446
Maven Surefire provides a facility for various "fork modes":
* forkMode=once: The default mode, spawns a separate TestNG process
(like the TestNG Ant task)
* forkMode=never: run TestNG in the same process as Maven, in an
isolated classloader
* forkMode=always: launch TestNG N times for N tests; if one test
segfaults or calls System.exit or something, the other tests can run
to completion safely.
I didn't test forkMode=always with TestNG in Surefire 2.4, and sure
enough it doesn't work at all. (It runs the tests but reports 0
tests passed/failed.)
It does work basically OK for JUnit, where classes are normally
isolated from each other, but I'm not sure it even makes sense for
TestNG tests, where one test may depend on tests in other classes
(multi-class dependent methods).
I can kind of hack it so it works OK if you don't have multi-class
dependent methods, but if you DO have multi-class dependent methods,
it fails with a TestNGException: "MyTest.testFoo() is depending on
nonexistent method otherClassSetUp".
What should I do here? Put in the hack and let the user figure out
the TestNGException if they try to use multi-class dependent
methods? Fail with a clean error if the user tries to use
forkMode=always with TestNG? Something else?
Should forkMode=always be a feature of TestNG somehow?
-Dan
