dfabulich wrote: > > Typically it's used for slow tests; you can identify a subset of tests > that you want to run and just run those. (You can even pull just one > method from Class X, and another method from Class Y, and so on.) > Thanks for the explanation. To me, this seems more useful for ad-hoc testing. During an automated build, I want all existing tests for maximum test coverage of the artifact.
dfabulich wrote: > > For TestNG, we have to hand it the entire directory, because any one class > may @dependsOn methods in other classes. > I see. Now, if the user can provide an option to Surefire, indicating that the unit tests do not have inter-class dependencies, wouldn't this allow to get back the old behavior? I.e. enabling Surefire to pass test classes individually into TestNG? dfabulich wrote: > > As for splitting them all up into separate txt files, the only way we > could do it would be to split the tests up into one txt file per METHOD, > which is way too many files IMO. > I would not have any problems with a single file per method. Indeed, I think I like the idea: Test methods are the units that succeed or fail, so if test method TestClass.testFoo() fails, I would investigate TestClass.testFoo-output.txt and can easily concentrate on its output without any need to skip over the output from all the other successful methods. I think that would be worth another option ;-) dfabulich wrote: > > It's odd that you describe this as a 2.3.1 regression... I couldn't get > TestNG to work at all in Surefire 2.3.x, hence my work on Surefire 2.4. > Using Surefire 2.3.x together with TestNG 5.1 worked for me. Nevertheless, it's good to have Surefire 2.4 now! Regards, Benjamin Bentmann -- View this message in context: http://www.nabble.com/Test-Suites%2C-Ant%2C-Surefire%2C-and-JunitReport-tp15076378p15093881.html Sent from the Surefire - Developer mailing list archive at Nabble.com.
