(sorry for mashing these together, my email client decided to download and make them vanish, so I've pulled these from a digest request)
>Funny that you should say this when I've been unable to find a single unit >test in all the plugins that currently exist for m2! :-) > > Yes, this is true. Some of them started out very simple, and some have integration tests. There were some tests, but they were problematic for the bootstrap (this should no longer be the case). >That said I would be happy if you can show me how to write a significant >unit test for http://rafb.net/paste/results/u2dtsf30.html > > > You've addressed some of this below, but for comments on this itself: #project.build.directory instead of #basedir/target and try not to use #project directly if you can avoid it (this removes a dependency on maven-core and makes it more reusable outside of Maven). >What is needed is a test project using the plugin because I need source dirs >and output dirs to test that Clover works. > Surely you can do that without an integration test, since you can feed in any parameters? >Of course I also need to validate >that all the plugin's magic (all the javadoc tags) works. > > This is true... > >I think we need to have a separate m2 project that tests the plugin >(functional tests). I can already do this but in the same manner that we >have asserts in the m1 plugin plugin we'll probably need helper APIs. I >thought this was what you were doing in the it tests with the >expected-results.txt and goals.txt files. The problem is that it was easy in >m1 to have a maven.xml file to define the test setup, decide which goals to >run and perform the assertions. Here's it's not doable easily (correct me if >it is) so we'll probably need support for this (this is what you're doing >with the txt files it seems). > > Well, I did say that I wanted to turn the verifier into an m2 plugin... so if it does what you want, it can be used for that. I guess we can make the "fork" of m2 be configurable. It's good for the integration tests, to be sure all of m2 is working, but individual plugins might not be so strict. >Yep, almost :-) > >I have spoken with Jason on IRC yesterday and he said I should speak to you >too but you were sleeping so I thought I might as well start something... >:-) > >My first ideas are: >1) Bind the plugin to the generate-sources phase > > Right, but you need to only activate it if clover is going to be used. The configuration triggering is probably too much here - we might need to look at an alternative. >2) Modify the project source roots to replace the main source root with the >one generated by Clover > >I have not thought at all about the reports, just about executing Clover for >now. > > Ok, but how do you see the user invoking this? I'm worried you are jumping down the implementation a little too fast... we need to think about how it will be used. Maybe the clover:on approach is right, but I'd like to think of alternatives first - does it make more sense to just run "clover:clover" and have that do the binding and run the tests (or configure a goal in the pom), or do you really want to have clover:on? > >I'm planning to use the following directory structure: > >maven-clover-plugin/ > |_ plugin/ > |_ pom.xml > |_ [this is the plugin itself] > |_ tests/ > |_ testAAAA > |_ pom.xml > |_ [...] > |_ testNNNN > |_ pom.xml > |_ pom.xml > >So that to build the plugin you would go at the top level and type "m2 >install" and it will run the integration tests too. > >What do you think? > > > I'm personally still in favour of single-artifact integration tests remaining in the same project, what do others think? maven-clover-plugin/ |_ src/ |_ integration-tests/ |_ testAAAA |_ pom.xml |_ [...] |_ testNNNN |_ pom.xml |_ [this is the plugin itself] |_ pom.xml >Reporting is only a second step. The first step is that you need to >instrument sources, get them to be compiled and executed. You don't want to >execute the report right away. I think it should really be a second step not >linked to the first step of getting the clover database ready (because the >clover db can be enriched in different manners, including running manual >tests). This is really how Clover works and this is why you have different >Ant tasks of CLI tools in Clover (cloverInstr and *Reporters). > > Makes sense. >Option 2 fits nicely for doing this but this is going in the direction of >clover:on as it's exactly what it was doing. > > Maybe it's just the naming that is problematic for me. There's a couple of things that I feel uncomfortable with: - the need to specify it all the time when you are using it - the ability to get the database out of sync when you request the compile without it, which could then generate an incorrect report. - doesn't gel with the lifecycle idea. Now, if we're not doing a clover report, we must be: a) building a database b) erroring out if a certain coverage level is not hit? without b or a report, I don't see the point unless I'm missing something. So if it's (b), you'd want to do it every time? So you would wire it into the normal lifecycle (though not into the produced jar). > >True but that's the user's choice. He may want to have the instrumented code >deployed (I do for example because I want acceptance tests to run with >Clover so that I can check how much they cover of the code). Of course, >there will also be some runs without clover but that's me the user who >decides this. > > Sure, but you need to build different WARs with different names (this is the intention of the "classifier" to build the same artifact differently and be able to recognise it). We need to do everything possible to prevent accidents. >>I'm still working on the idea of alternate lifecycles (there is a JIRA >>ticket regarding idea:idea and generated sources that covers the same >>idea, and this applies to all reporting). What this means is that >>clover:report would fork a lifecycle instance to run everything under >>its own parameters. >> >> > >More precisely, what parameters are you talking about? > > > the test inputs (or whatever goal is run, perhaps integration tests), would be the clover classes instead of just the normal classes. Thinking beyond clover, something might make a modification, not just an addition - so it needs to be in a separate area. >It is very tricky. I don't see how you could easily achieve this isolation. >I don't think running the normal lifeycle with clovered sources is bad at >all. If the user runs: > >m2 clover:on .... > >he knows he'll have clovered sources. In any case he should rebuild the full >thing with an automated build before sending to production so there's no >chance he'll make a mistake. > > > Yes, but I'm trying not to only think of clover here. There are other things that modify the codebase (eg filtering) that can really mess with you when you make a mistake. >I'm open to all suggestions but it has to remain simple I think... > > The complexity is certainly going to be in m2, not in the plugin or user interface... > > >I'm currently testing the modification of the source roots in order to get a >clover db when running something like: > >m2 clover:on surefire:test > >And I want to write a m2 project for performing functional tests of this. >This is where my other emails about testing m2 plugins comes into the >picture. > > Ok, well its a good start... I'll have to try and understand better what you are trying to achieve and whether there is a better alternative. This doesn't feel quite right (and certainly, surefire:test won't work - you need to run the "test" phase). Cheers, Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
