ok, I fiddled around a bit today with the clean plugin as a basic test case...
I really don't like the idea of putting setters on the mojo...not sure why, but it bugs me, probably because it is really only putting them there for testing purposes which is generally a no-no. 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. 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 :) So I am curious as to what people think about that idea of having the mojo's setup in that way? It seems a bit heavywieght for the clean plugin but how important is it to not put those setters on the mojo? I have always been a bit of a fan for the correct conceptual way as opposed to the cheap and easy...though the cheap and easy can be faster :) Another thought I had on this is that with this adapter approach it is real easy to show the template for the plugin and how to use it...and it offers a real easy stepping stone to understanding how maven is built deeper in...and how much is that worth? so I am not really proposing anything with this followup mail...I'll generate a patch with my first test case setup for the clean plugin and put that in jira... I am however wondering if people generally like the plexified approach for the plugin implementation? I wouldn't be adverse to converting a couple more over to see how they look....and it does make them feel a bit more modular and useful outside of maven for a toolset like axistools, sablecc, or javacc since normal people don't have a facility for injecting those params.. jesse On 2/19/06, Jesse McConnell <[EMAIL PROTECTED]> wrote: > > after reading up on mocks from the links that vincent posted, I am going > to take a stab at putting together a minor set of these to work with for a > couple of the plugins...just to see how it would work out. Hopefully I can > get with vincent a bit tomorrow to make sure I get it close to right the > first time > > jesse > > On 2/18/06, Brett Porter <[EMAIL PROTECTED]> wrote: > > > > Vincent Massol wrote: > > > I think what you're describing is a stub but not a mock. The advantage > > of a > > > dynamic mock is that you don't need to code any method. It's the user > > of the > > > mock which says what behavior it should have for the methods it calls > > on the > > > mock. > > > > You're right, I've always referred to stubs incorrectly as mocks. I > > meant a stub. I think it's in our interest to produce these to make > > testing easier and more consistent for everyone. > > > > I'm interested to see your thoughts on the mocks eventually though - > > I've never really done anything with them since I was reading JiA (which > > I don't have any more :( > > > > - Brett > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > jesse mcconnell > jesseDOTmcconnellATgmailDOTcom -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom
