> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos > Sanchez > Sent: samedi 18 février 2006 20:14 > To: Maven Developers List > Subject: Re: plugin testing > > I thought more about static mocks vs. dinamic mocks, i think this is > what you call stubs vs. mocks.
Not quite. There are 2 types of mocks: static and dynamic. They are different from stubs. I could point you at JUnit in Action where I've tried to explain the difference ;-) but here's another explanation: http://martinfowler.com/bliki/TestDouble.html > What I found is that while jmock is great for certain cases, like > throwing an exception as you say, for other common tasks static mocks > are easier and require less test code. I don't quite agree... :-) When this happens this is a code smell. As I said either you're mocking too deep or your code has a design issue. Here's a very good article on the topic of using mocks: http://www.jmock.org/oopsla2004.pdf I do agree though that there are some very simple cases when you don't need a mock at all. For example when you have a data object there's usually no point in mocking it. Anyway, YMMV. Mocks are great but are also difficult to understand and use properly. This is probably the reason people are not using them more. I think using mocks purely for testing is an error. They should be used in conjunction with the desire to improve the design of the code they are testing. -Vincent > On 2/18/06, Vincent Massol <[EMAIL PROTECTED]> wrote: > > > > > > > -----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] > > > > > > > -- > I could give you my word as a Spaniard. > No good. I've known too many Spaniards. > -- The Princess Bride > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
