jason and I had a nice chat about this on #plexus today when I asked a question about getting the right logger instance inside of an object built out by lookup(ROLE)..
Here is the framework that we worked out...there are two lvls to it but in a nutshell it is a nice approach I think, very much along the lines of what brett was talking about. First off we build out a AbstractMojoTestCase that is a child of PlexusTestCase and in this we add a method that can be used like this: MyMojo mojo = (MyMojo) lookup ( Mojo.ROLE, path_to_pom ); now, the way this works is that in the src/test/resources (or whatever) directory we start building out a number of directories for different test cases and in those directories we put pom.xml files that contain the plugin declaration and the configuration parameters... these poms can be used in one of two different ways: 1) they can be used to instantiate the mojo through the above lookup method inside of java unit tests, giving you the fully instantiated mojo that you can execute all of the unit tests you like 2) they can be iterated over in a testing battery where we can do verification on the output of the plugin, a la the integration tests the lookup() method above can use the default plugin manager for a lot of the work I guess. Some of this gets into murky territory for me since I haven't dug into that area of maven, but it all seems like it ought to work pretty smooth. We would probably want to split out the directory structure for the 1) and 2) points above so we can distingish between them in the test running harness but...or perhaps even just use the embedder/integration plugin for much/all of the second one, depends on what kind of verification system we want to use. But the interesting part would be the ability to use the mojo lookup much like bret was mentioning above. so if people are comfortable with this approach I'll work on hammering out a moderately working implementation so we can make sure the api is clean and what we are looking for. jason was very keen on the something along the lines of lookup(mojo, configuration) but we started getting bogged down in details on what that object would look like since it would need to seed the mojo for an arbitrary number and type of private variables... the nice part of using a pom is that we get a pretty good build out of the whole deal, dependencies and all if need be...and it is a _very_ natural extension for maven and mojo users. We can provide a few examples of building out the test cases and it should flow very naturally...and what I like, expose people to a bit more to the way plexus is used to build objects in maven... hm...and the same deal might work if you were wanting to put a inner class extending abstract mojo test case on the mojo for testing private methods...kinda interesting anyway thoughts? jesse On 2/21/06, Brett Porter <[EMAIL PROTECTED]> wrote: > > Thanks for this! > > Jesse McConnell wrote: > > 1) so I did it once with just a normal junit test class and put the > setters > > on the mojo. Very little new code had to be added to get it working and > it > > was trivial to take that plugin up to about 85% coverage...the remainder > > being some workaround for a windows jdk shortcoming. > > I almost get 100% on Windows :) > > Just needs a test that if you try and delete something that's not > allowed to be, it throws an exception. And test John's changes that came > after this :) > > > 2) then I redid it using the approach that Trygvis was doing in his > > deb-maven-plugin where you make the mojo a basic adapter to the > > implementation which is put together in a standard plexus layout....this > > forced the generation of a fair bit more code and a couple of additional > > classes, but it certainly felt more true to the nature of what a mojo > > is...at least my perception of what a mojo is :) > > http://cvs.codehaus.org/changelog/mojo?cs=1478&@csTruncateDiffs=false# > > I recently did the separated content and found it extremely tedious to > implement, so I moved back to not doing that - but it depends on the > situation as we generally do what you are suggesitng anyway. > > The original idea was for a mojo was that it could be reused anywhere > (automatically generating an ant task wrapper, for example). I think > we've steered away from that practically though idealogically would > still like them to be the reusable components. We steered away mostly > because: > 1) the plugin api dependency and extending AbstractMojo > 2) the amount of extra work it is to populate the mojo variables, > especially when it comes to wiring up the plexus components which is so > wasy as is. > > I think its good to abstract things out like you've done to a degree, > but I think the right level for clean is pretty much where it is: > deleteDirectory. Some of this needs to move to plexus utils, and the > clean plugin should really be delete target, delete output, delete test > output. WDYT? > > So far the approach to factoring has actually taken components out of > the plugins themselves - plexus-compiler, plexus-archiver, plexus-utils, > etc. I'm actually happy to continue that way for now to clearly separate > the responsibilities and build libraries that are reusable outside of > Maven entirely. A lot of these are being pushed to Jakarta commons since > they originated from code in Ant that is also being developed there. > Others go in Maven and its sandbox (the issue tracking stuff, the SCM > library, the JXR library, ...) > > As far as "plexifying" goes, that's probably not the right word, as > Plexus isn't being used to instantiate the CleanPlugin object. > > This is where the testing toolkit might come in - it would do the plexus > component instantiation of the plugin, so rather than requiring: > plugin = new Plugin(); > plugin.setComplexObject( constructComplexObject() ); > You'd have: > plugin = (Plugin) lookup( Mojo.ROLE, "goal-name" ); > with everything wired up, just like it is done in the plugin manager. > And then you use the setters to add the customised stuff. This will > probably be more obvious when it comes to the site plugin. > > I think the unit tests are a great start though, and we can probably > tackle some other plugins and see how the other issues go (something > that has fields with more expressions or @component references). > > I'll apply the first patch. > > Cheers, > Brett > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom
