On Mon, 31 Oct 2005, Vincent Massol wrote: Hi Vincent,
> > I'm not sure.... Have a look at the POM lifecycle. You'll see it doesn't do > much. Of course I have been able to solve my need by adding to the POM > lifecycle: [snip manually adding compiler/surefire] > But that's a bit heavyweight and I think integration or functional tests is > common-enough use case for offering a built-in solution for it. Agreed. M2 itself uses 'jar' packaging for integration tests. The only difference is possibly that those projects don't need to be installed/deployed, but otherwise are the same as normal jar projects. So you might have a good point here. > > > - more importantly the tests that I currently put in src/tests/java are > > not > > > executed. > > > > If this is a typo: either use src/test/java or src/it/java (if the it > > plugin is finished ;)) > > I don't understand why you are promoting src/it/java. My understanding is Sorry, my mistake. I meant src/it/[project]/. > that there are 2 types of sources: > - the one that will be packaged and executed at runtime. They go in src/main > - the one that are tests (any kind of test and test resources). They go in > src/test. Yes. > Thus for example: > > src/test > |_ java (unit tests) > |_ it (or integration or functional for functional tests) I believe functional tests fall in another category dimension. We have 2 axes: Unit test --------- Integration Test, and orthogonally to that: Basic test --------- Functional test Unit/integration test depends on wheter sub-components of a project, or the entire project, possibly in a larger 'environment' is being tested. Basic/Functional test is internal/external api testing. At least that's what I've come to understand at my last job. :) > |_ groovy (for groovy tests) > |_ cactus (for cactus tests) > |_ resources (for tests resources) > |_ resources-it (for it test resources - for example) I don't think we should separate sources depending on testing framework. Since they have to be defined in the pom anyway (the plugins for that), you can just use src/test/ or src/it for that, and if you need multiple tests (are they guaranteed to work on different source sets?) you can always manually add directories... > What we definitely need are naming conventions that we would all agree on > but this will come when plugins are there. Right. > I still don't understand why you want to have src/it. Integration tests! Multiple possible projects to run the code of the 'main' project (including runtime dependencies) against. Say, maven-core-it/it*/ -> src/it/*, and for the maven-eclipse-plugin: src/test/projects/project-X -> src/itest/project-X and drop src/test/. > > If this is NOT a typo: weird, I didn't know specifying packaging pom > > didn't run any tests. > > No it doesn't. Again have a look at the pom packaging lifecycle. You'll see > that test compilation and test execution are not bound. I'm lazy.. ;)) > > How about just specify packaging 'jar' for now? > > I'm not generating a jar. My current solution is to use pom and augment its > lifecycle as shown above. > > > > So I think we should have a "integration-test" packaging that would map > > the > > > test directory to be src/it (for example). > > > > If the above are resolved I don't know why.. it's a phase. It's weird > > enough that the test phase is also a valid attachment, but since that road > > was taken, I guess integration-test could be a valid attachment too. > > > > > Obviously another solution would be to use the it plugin but it doesn't > > do > > > what I need. I need to write my test logic above the execution of the m2 > > > projects so that I can do some setup and perform possibly complex > > assertions > > > that wouldn't be supported by the verifier plugin for example). > > > > You were going to give me some feedback about this :) > > Yep. Here's some feedback in this email. I'll provide more in a few days. > :-) Great, thanks ;) > > I think the it plugin does exactly this. You specify tests per project (or > > even 'inherit' them using dependencies) so you can do whatever you want in > > the test phase - check for created files, etc.. You can even bind stuff to > > the integration test phase of the integration test projects so you'll have > > a finished artifact to run tests on. > > Ok, I may have misunderstood the it plugin. Could you tell me how do I > control the setup of a test using the it plugin? Let's imagine I want to > dynamically change a m2 property before the tests is executed or that I want > to execute several goals depending on some code logic. How do I do that? > > The example you've listed above seem to be linked to assertion about > results. This is the quivalent of an after() advice in AOP-AspectJ-parlance. > What I'm after is the equivalent of an around() advice. I've been able to > get this easily using the embedder. > > Can this be done with the it plugin? Not yet, because I didn't see the need for it yet. I believe that you can specify all settings/parameters in the pom itself (pre() advice), and can write after() advice as unit tests. > > You can specify the configuration in the pom - the only official api to > > communicate with plugins. You don't need to write unit test code just to > > set up a plugin. You can always write a custom 'verifier' plugin and bind > > that to your integration test phase, doing the complex assertions. > > > > So why isn't the it plugin good enough? Too complex, too repetitive work > > (configuring different pom.xml's?) Not flexible enough? > > See above. - Changing an m2 property.. which one, why? - Run several goals: just specify them in the pom as defaultGoal or bind some non-lifecycle mojo's to the lifecyle, or specify the goal to run in the it plugin's config (currently it's global - one 'goal' for all projects, but the defaultGoal might help here). I agree that the it plugin could be augmented so this will be easier. > > As for the assertions, I was thinking about porting some tests from the > > verifier plugin (the maven-core-it one) to the it plugin, but I need to > > know what kind of assertions you want to do. > > > > Hope to get some feedback! > > Yes, I'll give you some more detailed use cases once I have progressed a bit > more. Give me 1 or 2 days more! I'm working on it today and tomorrow. Ok, good luck! > > Thanks > -Vincent > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
