Vincent
"fancy name ! I am now wiser than before ... :)"
Upon rereading that, I can only conclude that my inner academic made a
stealthy strike before the send command. :)
"I'm still not convinced of the advantage of these inner classes of yours
...
I don't see what advanatges it brings ... Because anyway you need an
implementation of the mock (be it static or dynamic). Now what remains is to
define your expectation on the mock object and this is easily done by use
method calls to setExpectedXXX()-like methods. Something I am missing ?"
With a proxy, you generally only need to mock a couple specific methods
rather than the whole interface. If an interface does not exist, then what
are you going to do without inner classes to mock specific methods an
implementation class?
If you have the chance, I would like to see some code that allows for the
setExpectedXXX() methods you are referring to. Is it in the mock object
source that I have on hand? Do you have to write a special mock class for an
interface to track methods calls and parameters? If so, let's reverse the
question and ask why write a library to set and test expectations when it is
easily done by using features of the platform itself?
Also, I don't want to get into too much detail until I get some feedback
about the last version of the article I posted here, but the use of inner
classes that set outer class variables makes the use of the Verifiable
interface unnecessary in many cases. Furthermore, when you are testing the
method of a particular class, you can override other methods of that same
class to check expectations on inter-class calls.
Tom
