2012/12/2 Jason van Zyl <[email protected]>: > I think the way the ITs used to work was better. Where a single project was > entirely self-contained and there was a declarative file that described the > desired outputs.
Well I think this is one of the design goals I *almost* managed to achieve when I refactored the surefire IT's; the supplied test project can run with "mvn clean install" straight out of the box to demonstrate the problem (as described here http://maven.apache.org/surefire/maven-surefire-plugin/developing.html). (This is where I think invoker fails miserably). In surefire I did this by using the system properties for the plugin parameters as well as defining standard "properties" in the poms for all the props without predefined -D values. Writing the actual IT to do the assertion is a walk in the park, and there's a quite high percentage of surefire patches that actually contain well-functioning IT's. (This may be related to personal beliefs of anyone submitting patches to a test framework ;) The core IT's are probably the most complex ITs in all of maven. They are still not *that* much more complex than the surefire IT's used to be, where the simplification seems to have paid off well. The effort of rewriting may not be worth it (although it was in surefire), but establishing a clear norm for "nice" tests that can be documented is always a good thing. I'm no big fan of BDD frameworks like jbehave or cucumber; I think simple "java" based DSL's do the job better; especially with what is essentially a very limited domain like this. I like runnable junit tests that apply to "real" runnable projects that can be made by end users. I'm a programmer dammit ;) Kristian --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
