Dan Fabulich wrote:
John Casey wrote:
What you're seeing as overlap is a mixture of concerns in the invoker
plugin. The verifications beanshell really needs to be migrated out to
some sort of proper integration-testing plugin (or, even better, a
plugin that unites invoker and verifier under a common
configuration...then extend the verifier with the invoker's beanshell
functionality). Regardless, the invoker plugin can be used for any
sort of scenario where you need to fork a new maven process. I've
personally used it to proxy secondary builds in some sticky client use
cases. You don't have to use the beanshell script to verify the build,
it's just an [admittedly confusing] option.
As I've remarked before, I find it weird that various Maven developers
have gone and written _plugins_ to do Maven integration testing.
Integration tests are just tests; we know how to write/run tests using
real test frameworks like JUnit and TestNG. Those frameworks are pretty
cool; you can do stuff like rerun failures-only, graph results over
time, write data-driven tests, etc. You can even use them to write
tests in scripting languages like Groovy, BeanShell, etc. All that AND
you get excellent IDE integration.
More generally, while I certainly see the value of a
maven-invoker-plugin, I don't expect that you'd want that to be the
"normal" way people would write Maven integration tests.
Right now there are four things: maven-verifier, maven-verifier-plugin
(no relation!), maven-invoker, and maven-invoker-plugin.
I think I'd like to advocate ripping out the bulk of maven-verifier and
make it depend entirely on maven-invoker. Since maven-verifier is so
confusingly named, I think I'd want to take the good bits out and put
them in maven-integration-test-helper (which is what maven-verifier
really is, anyway).
More controversially (?) I'd like to deprecate the idea of writing
*tests* using the maven-invoker-plugin, instead preferring to write them
in Java (or BeanShell, I'm easy!) running them using a "real" test
framework. maven-invoker-plugin should still be used for spawning
sub-builds in those delightful cases where that's necessary.
Thoughts?
Dan,
I agree with you - integration tests would benefit from having a more
unified approach, just like unit tests are run by surefire. It should
support different languages, Java and scripting, and different runners.
I would still have a different plugin for ITs than for unit tests, as
they typically are run with different usecases, and I fear that surefire
would get overloaded.
Cheers
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
