> -----Original Message----- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: vendredi 17 février 2006 23:59 > To: Maven Developers List > Subject: Re: plugin testing > > > I think this is the right separation. Unit test to get coverage, add and > use setters like Vincent suggested. Integration test to verify things > like the lifecycle intereactions, etc. controlled by the annotations at > the class level. We can already do both. > > As Carlos mentioned, getting the objects is difficult. We do need a mock > MavenProject instance, and can use PlexusTestCase as the base to be able > to lookup components to set. > > Eventually I'd suggest creating a new module with an abstract test case > that extends PlexusTestCase. This can be used to lookup components to > set (and possibly automatically wire them up which would be much more > convenient): > > setUp() { > mojo = lookup( Mojo.ROLE, "goal name" ); > } > > In this case we also need to have an expression evaluator replacement > that will provide replacements for ${project} and ${settings}. > > I'd start by manually injecting those values though and see how it goes.
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. This seems to me the best possible thing because: - it makes it easy for the user to have several tests with different values coming from the mock whereas with a stub it's not always going to be easy to configure everything you want the way you want it. - it's hard to test exception in a stub whereas with a mock you can say that for this test you want such method to throw such exception. My belief is that people do not know mock objects (e.g. jmock) and this is why they think it's difficult (in most cases they think mock = stubs). I have the feeling that providing samples on the web site of how to use jmock to test a plugin would solve a huge percentage of unit testing cases. Last, when your unit test has to use too many mocks and define too many behaviors it means 2 things: - you're not mocking at the right level (you're going too deep) - the API is bad and needs refactoring [snip] Thanks -Vincent --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
