John Casey wrote:
First things first. maven-invoker and maven-invoker-plugin are not separate things. The maven-invoker-plugin uses maven-invoker, but maven-invoker is meant to be a reusable library, not just a plugin.
I find this remark quite confusing... if one is a library, and one is a plugin, and they have two separate POMs, one for the library JAR ("maven-invoker") and one for the plugin ("maven-invoker-plugin") doesn't that make them two things that share code?
Actually, I think our "disagreement" is mostly a misunderstanding, and I think it mostly turns on this point of whether maven-invoker and maven-invoker plugin are "two things."
In particular, I said that we should not use maven-invoker-plugin for integration testing. But I didn't mean that we shouldn't use maven-invoker!
e.g. when you said:
Also, I'd like to know how you would suggest writing integration tests using junit without the invoker functionality (the real meat of the invoker plugin) and without access to the maven 2.1 embedder (it's not available in any real way in 2.0.x).
I never meant to suggest that we'd write integration tests without the invoker. I meant that maven-verifier should *use* maven-invoker (the library) and should continue to execute a separate instance of Maven.
We're in total agreement that integration testing should happen by running real Maven projects and executing a real Maven to make that happen, for all the reasons you laid out.
[I also argued that we should rename maven-verifier, because its name is confusing.]
With that said, I think there is still a point of actual disagreement lurking here which I'd like to flush out... namely whether it's best to write your tests in Java/JUnit/TestNG or whether you'd want to have/use/write a test-runner plugin (beyond Surefire that just runs JUnit/TestNG) to handle these tests.
More generally, I think plugin integration test writers should write their tests in the maven-verifier style (using a maven invocation library [e.g. maven-invoker] under a JUnit test), and not using maven-invoker-plugin.
I think that because both tests of Maven Core and integration tests of a plugin call for doing the same thing: invoking Maven and asserting on the results.
JUnit is best suited to unit tests, as its name suggests.
True, though JUnit is acceptable for integration tests too, (especially JUnit 4) and TestNG is great for both. The two of them together beat the pants off of almost everything else in Java land.
The maven-verifier (not the verifier plugin, I know it's confusing) gets away from this, in that it requires a project directory in src/test/resources AND a JUnit test case to orchestrate the test. IMO, this makes it extremely difficult to run a single core integration test from the command line, so you can capture logs for offline examination, for instance.
With that, I definitely disagree. Can you say more about what's difficult about running a single test?
Certainly it's trivial to run a single JUnit test from the command line using Surefire: "mvn test -Dtest=FooTest" does the job nicely; I use that all the time. And it's REALLY easy to run a single test from Eclipse/IDEA.
Maybe you meant that you think maven-verifier tests are harder to WRITE than writing goals.txt + beanshell tests? (I disagree with that, too, but it's worth clarifying what we're talking about.)
Again, the idea behind test builds driven by the invoker is to provide a test suite with a low barrier to entry, and with all the potential for configuration present in the main user's experience with Maven. It's not a panacea, but neither is writing JUnit tests that orchestrate and verify test-build resources in a separate directory structure, which can really only be run properly from the JUnit api.
You call it the "JUnit API" like it's this big hassle to run JUnit tests... but it's really easy to run JUnit tests, both from the command line and from an IDE; certainly 99% of our users know how to do it, and I hope most of them do it frequently! :-)
Furthermore, you seem to imply here that you can't just cd into src/test/resources and run the projects there by hand directly... but of course you can do that when you want/need to. I often do that when I'm first setting up an integration test, before I've written the JUnit assertions for that test. Occasionally I do that when a test fails just so I can make sure I can reproduce manually what the test is doing automatically.
However, it's also critical to allow a project's POM to remain unmodified for the purposes of orchestrating or verifying the build. Modifying the POM introduces the potential to taint the test results, and can limit flexibility in terms of verification. For instance, if you need to simply scan the console output for a particular message, it becomes much more difficult to do this if you try to do it while the build is still running.
I don't understand this remark, because I don't think either strategy requires anyone to "modify the POM"...? I hope it's just an artifact of the earlier misunderstanding.
-Dan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
