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]
