Alexandru Popescu ☀ wrote:
As I see it, here are the options:
1) Don't support mixing JUnit tests with TestNG tests in a single Surefire
execution. Clever users can, if they absolutely must, try to configure
two executions of Surefire, one of which has junit=true, the other of
which doesn't. The advantage of this is that this is what the code
already does.
2) Try to write the code to separate out the tests ourselves in Surefire.
(This is high magic... I don't think I want to do this.)
Frankly, I don't like either of the options, but if I had to pick, I'd
pick #1.
Don't remember the specific code, but do you have access to the class
or is it just a string? Because if we have a class then we can test
for its JUnit inheritance to determine if it is or not JUnit.
Otherwise, I think I would go with 1.
Good suggestion, thanks. I've written up some code on my machine that now
knows how to run TestNG twice: once with all of the TestNG classes
and then again with the JUnit classes (if any).
However, this naturally creates some trouble, as running TestNG twice
results in the testng-results.xml getting clobbered; only the second of
the two runs appears in the final testng-results.xml. (Both tests appear
in Surefire's JUnit XML report, because Surefire generates that by
attaching listeners and creating the XML by hand.)
Right now Surefire is using the convenience helper in TestNG that allows
you to pass the TestNG object an array of classes; this will automatically
create an XmlSuite for those classes using the private
createCommandLineSuites function. That function is pretty complicated; it
searches through the classes to see if they have an appropriate xmlSuite
or xmlTest attribute and uses that if possible. I'd like not to duplicate
it in Surefire if I can avoid it.
To get this to work, I think I'd need to be able to tell TestNG that I've
got one suite with two arrays of classes. The JUnit array of classes
should be pretty simple (just junit=true, classes=blah) but the TestNG
array of classes needs that fancy xmlSuite detection logic in TestNG.
This code is already more complex than I'd like, and isn't really very
general. (What if the user has JUnit 4 + TestNG on the classpath?) I'm
therefore ever more strongly inclined to just rip out supporting mixed
JUnit/TestNG.
Thoughts?
-Dan
