well, what I have been working with uses precious little of maven, and jason set up the project at mojo so I could do commits on it and we could collaborate.
Here is the nut that I am trying to crack: Mojo's need some way of being tested and having coverage determined. This is complicated by the fact that mojo's have a couple of different ways of being initialized, either though private variable injection or in some cases getters and setters. There is also the little problem Maven objects that need to be stubbed out and to act correctly so the mojo code can be tested against them outside of the maven execution engine. There hasn't been any resolution on mojos using private variable injection/getters and setters/or both issue so we need some mechanism of populating the mojo's which is where the use of plexus comes in. way back up in the thread there were two different concepts thrown around, 1 was 'unit' testing the mojo's which would be getting an instance of a mojo populated and then the massage it through different means to increase coverage. the other was more of an integration with maven idea where it would tie into maven itself and each plugin could have what would amount to an battery of integration tests available. hope that kinda summaries things up to this point. jesse On 3/7/06, Vincent Massol <[EMAIL PROTECTED]> wrote: > > I guess the terminology is still an issue but what the it plugin does and > what Jesse is implementing are for me integration tests and not unit > tests. > > Unit testing a plugin would be, for me, testing it in java, in isolation > from the execution engine (ie. Maven). > > I know I'm not answering you question though... Still think that it's > important we have a common terminology WRT plugin testing. > > -Vincent > > > -----Original Message----- > > From: Kenney Westerhof [mailto:[EMAIL PROTECTED] > > Sent: mardi 7 mars 2006 13:14 > > To: Maven Developers List > > Subject: Re: plugin testing > > > > On Mon, 6 Mar 2006, Jesse McConnell wrote: > > > > Hi, > > > > (It took me a while to find the code - [EMAIL PROTECTED] and the heave use > > of > > maven internals suggested it was in the maven sandbox :)) > > > > I'm catching up to this thread, and I'm wondering what the exact goal > > of this effort is. > > > > Specifically, wheter it is meant for unit tests, and wheter it is > > possible to somehow merge this with the maven-it-plugin, binding > > some test to the (pre-/ and post)integration-test phases. That way, > > you can rely on the Embedder to do all the configuring and setting > > up the environment, which really seems what the bulk of the > > maven-plugin-testing-harness is trying to accomplish. > > > > Custom configuration of other project aspects like a local repository, > > stubs and whatnot could be put in a mojo that runs prior to the > > maven-it-plugin's main mojo (ForkMojo); the pre-integration-test phase > can > > be used to set up the environment (or integrated more in the > > ForkMojo on a per-project basis), and the post-integration test phase > > could contain the unit tests to validate the plugin execution. > > > > I'm just tossing this in, since it seems that this effort overlaps > > with my initial ideas for the maven-it-plugin (basically, > > running unit tests for plugins withing a maven environment). I'd like > > to understand why this approach was taken (philosophy mismatch/the it > > plugin still being in the sandbox? :)) > > > > -- Kenney > > > > > > > On 3/6/06, Brett Porter <[EMAIL PROTECTED]> wrote: > > > > > > > > Jason van Zyl wrote: > > > > > This was just the first stage. I just whacked in the DOM reader > > because > > > > > we need some more testing code to create a local repository for > the > > > > > MavenProjectBuilder. The MavenProjectBuilder should be used. > > > > > > > > A stub of the maven project builder, or the real one? The real one > > uses > > > > the repo, and that's not really conducive to unit testing. > > > > > > > > > > > > the repo will need to be real at some point, some plugins needs to > > interact > > > with the real thing, for getting jars for packaging or for just > looking > > into > > > for resources or something..so the artifact repo seems to be a > required > > part > > > of actual unit tests.. > > > > > > > > > > Why? I don't think you should have to add methods in order to be > able > > to > > > > > test the mojos. It's not how they would ever be used, so you're > not > > > > > really testing how they would be used in the field by adding > > properties. > > > > > > > > At one point, we were doing away with private field injection and > > > > recommending setters, so it is how they'd be used. > > > > > > > > > > > > > > I think the POM style testing will be most familiar to people > > writing > > > > > plugins and ultimately allows for completely declarative testing > of > > > > > Mojos which I think would be excellent. In almost all cases you > have > > to > > > > > execute the mojo in order to test it and in order to execute it > you > > need > > > > > to populate the configuration elements. You could very clearly > > outline > > > > > different test scenerios using different POMs. You could do this > in > > Java > > > > > but does it really matter if the inputs come via Java or another > > > > > mechanism? I honestly don't think so. > > > > > > > > No, neither do I. I said having both is a good idea, but that > calling > > it > > > > a POM is misleading, and to cut it back to just a configuration. > > > > > > > > > simple, I'll take care of this today... <plugin>-config.xml maybe? > > > > > > > > > > > > At any rate I don't think you should alter classes for testing. > > > > > Especially in this case as we know Mojos work just fine without > > > > properties. > > > > > > > > But they *are* properties, it's just a matter of whether it is > > injected > > > > using private fields, setters or constructors. Adding getters is > > > > probably a bit more lame, but I think that's unavoidable in either > > case? > > > > > > > > > I think we can get away with all this without actually needing to add > > > getters and setters, personally I think adding setters somewhat clouds > > the > > > interaction with mojo's, have a combo of setters and private field > > injection > > > seems prone to some kind of abuse > > > > > > > > > > I think the Artifact/MavenProject population could use a little > > tweaking > > > > > but we could probably do that with a special expression evaluator. > > > > > > > > Cool. I have to look at the actual code yet... > > > > > > > > > I think people writing tests will like this declarative method of > > > > > writing tests. It will be less error prone and take less effort > and > > > > > provide a standard way for writing Mojo tests. > > > > > > > > In some cases, but when you are only setting one field, its a pain, > > and > > > > when you are doing the same thing over and over and changing one > > field, > > > > it's a pain (though you could combine the two techniques for that). > > > > > > > > > I was getting visions of people just making one test pom and either > > reusing > > > or copying and modifying a bit. > > > > > > > > > > I think we can easily provide some Java code for those that want to > do > > > > > the Java thing but I imagine the desire to do that would fade > given > > the > > > > > declarative option. But you still shouldn't have to add properties > > to a > > > > > mojo to make that work unless that's what you wanted to do to make > > it > > > > > reusable. > > > > > > > > As long as the assertions are still in Java, I don't think its a > > > > declarative option, and I'd prefer to have my pre-conditions next to > > the > > > > post-conditions to make the tests more readable, myself. > > > > > > > > > > > > I agree with you here, it is disjointed to have the configuration and > > the > > > asserts in another place...but if we are going to route of a new file > > for > > > configuring these things, how about just building out an assert setup > in > > the > > > configuration xml? > > > > > > <test> > > > <configuration> > > > ... > > > </configuration> > > > <asserts> > > > <assertTrue>expression</ > > > .. > > > .. > > > > > > The expression could be fed into the test case somehow...then they are > > bound > > > together > > > > > > jesse > > > > > > -- > > > jesse mcconnell > > > jesseDOTmcconnellATgmailDOTcom > > > > > > > -- > > 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] > > > > > > > > ___________________________________________________________________________ > Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les > tarifs exceptionnels pour appeler la France et l'international. > Téléchargez sur http://fr.messenger.yahoo.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom
