Carsten, Agreed on a preference for runtime mocks (although I find Mockito's syntax much more readable than JMock, which turns my brain into a pretzel).
But the compile-time mocks I needed in this particular case already existed (for the most part), so it seemed better to extend them. Jeff. -----Original Message----- From: Carsten Ziegeler [mailto:cziege...@apache.org] Sent: 07 December 2011 10:29 To: dev@sling.apache.org Subject: Re: Backwards compatibility in Mocks: how far to go? Hi, I'm not against enhancing the current mocks, however I ran into similar problems as you and decided to copy the code or create new mocks. This reduces dependencies and ensures that the mock really behaves as you expect. In addition I prefer using jmock (or similar libs) to create mocks on the fly. Regards Carsten 2011/12/7 Jeff Young <j...@adobe.com>: > We've got some Mock... classes in org.apache.sling.commons.testing. > > Generally speaking, these mock the methods the original author needed, and > return null/false for all the rest. > > However, there comes a time when someone else needs a Mock of the same class, > but with a few more of the methods implemented. I've found a couple of cases > where the Mock classes were copied into the relevant test cases and then > modified, which seems a shame. > > I've fixed up some of those by introducing secondary constructors. (Most of > the modified Mocks needed more constructor parameters to implement the new > methods anyway, so this sort of came for free.) So, call these Mocks with > the old constructor and you'll get old behaviour; call them with the new and > you'll get new behaviour. > > But I've got one where the implementation of a mocked method was just a > little too simplistic. I've modified it to do the right thing, and run all > the tests I know about. But of course there might be proprietary tests that > I don't know about, and while unlikely, it's conceivable that they could rely > on the old ("less correct") behaviour. > > I could add a new constructor with a "fake" parameter (say, int apiVersion), > and let it control the behaviour of the two methods. Or, we could say that's > too much noise in the code, and if someone updates their testing bundles to > newer versions then they should get the "more correct" implementation (which > might show up some real bugs in their tests anyway). > > WDYT? > > Thanks, > Jeff. -- Carsten Ziegeler cziege...@apache.org
