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]
