http://jira.codehaus.org/browse/MNG-2093
for the regular test case patch and then the plexified approach as well On 2/20/06, Jesse McConnell <[EMAIL PROTECTED]> wrote: > > 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 pluginbut > 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 -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom
