Re: [Cppunit-devel] Mock C++

[Baptiste L. <gai...@fr...>]

----- Original Message -----
From: "Philippe FREMY" <P.FREMY@OBERTHURCS.com>
To: <cpp...@li...>
Sent: Wednesday, August 14, 2002 5:59 PM
Subject: RE: [Cppunit-devel] Mock C++


>[...]
>
> Your example is not exactly crystal clear to me. Tell me if I understood
> correctly:
>
> 1. class ProjectBuilder has methods beginGroup(), endGroup() and
> addSouceFile()
Yes.

> 2. to record the call being made, you use the addActual() function
Indeed. _methodCalls is an ExpectationStringSequence. It expect a specific
sequence of string. Since the string added are the method name, a specific
sequence of method call can be specified that way.
>
> 3. to record the arguments of the functions, you use addActual() on
> ExpectationStringSequence that are specific to a function.
Yes, but that's because my arguments are a single string. I could use an
expectation sequence for a specific struct that represents the arguments or
one expectation sequence for each argument.

> 4. the setExpect stuff is here to match expect vs actual
Yes. You use those methods to specify what you expect to happen.

> 5. you do not handle return values.
In that particular case, I did not have any return values. I don't see a
problem handling them. Just like expectation sequence, you store a list of
value that you use at a later time (though I have not yet implemented such
helper for sequence or associative containers).

> If I understood right, your framework does not look very generic to me,
and
> requires many manual calls. I think we can do better.
It is fairly generic: you don't have much restriction in writing your
expectation and you can easily add new one. What you probably mean is that
it does not automatize the creation of such class.

> To record the called made to a function, we could add a simple macro just
> after every function calls. Compilers usually have a __FUNCTION__ that
> contains the name of the function, so this could be automatic. It would
gcc does, but I don't remember VC6 providing that.

> record the function being called. Using a dictionnary behind that, you
would
> be able to store and retrieve specific information about each function
call.
I could be done, but I have an hard time seing how you would fill that map:
you are not in the function and the value returned will unlikely be portable
across compiler. Also notes that in the provided example, I was tracking the
call sequence for all methods. Sometime you are only interested on some
specific method call count. You implement this by using a specific
expectation call count for each methods.

Also, notes by doing that you're being a lot less generic: you force the
user to write mock object in a specific way.

> If we assume all objects can be compared using their string
representation,
> we can store the expected and actual arguments of every function.
Urk. Never do that. String representation should only be used for diagnostic
purpose, never for 'business' stuff. I actually do that by providing functor
(with default) for equality and string conversion. Equality is a very
volatile things when writing unit test. Sometime you need strict identity
(an object can only be equal to itself), sometime you only need a similarity
comparison (the objects have the same caracteristic).

> The only thing I haven't been able to figure out yet is how to handle
return
> values.
I would use something close to the expectation sequence, using a
getExpectedValue() instead of an addActual() method.

>
> I'll read some C++ books and see if I can find a solution.
>
> regards,
>
> Philippe
>