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.
