RE: [MO-java-dev] First batch of questions on new Dynamic Mock API

[Vincent M. <vm...@pi...>]

> -----Original Message-----
> From: Tim Mackinnon [mailto:tim...@po...]
> Sent: 13 May 2003 01:51
> To: Vincent Massol; Mockobjects-Java-Dev
> Subject: RE: [MO-java-dev] First batch of questions on new Dynamic
Mock
> API
> 
> Vincent - I think you seem to be panicing a bit. If you slow down a
second
> and look at the example you will find its not as bad as you think -
there
> are some useful comments in the actual test, and many of the
parameters of
> the methods you are calling have pretty explicit names. If you recall
I
> did
> send you a long message documenting a lot of this stuff for you
already,
> however as I know you have a tight deadline I will repeat and clarify
some
> of this stuff so you can go faster.

Thank you Tim and sorry. I did remember you sent me some long emails and
I had stored it for when I would need it. I've tried to find it again
and I found several emails where you describe the new mocks but either
I've lost your email (shame on me!) or you did not go into the details
I'm asking below as I could not find answers for that.

> 
> > - what is now replacing the setupDefaultResult() method?
> >   Ex: mockRequest.setupDefaultResult(String.class, null);

Any answer for that?


> >
> > - what's the difference between expect*() and match*()? It seems to
me
> > that the verify() will trigger a check to verify that the expect*()
> > calls did actually happen whereas this would not be checked for the
> > match*() ones? Is that correct?
> 
> As Steve correctly pointed out - matchAndReturn does this. 

Does what? My questions is "simply what's the difference between
expect*() and match*()"...

> There is a
> comment above these lines saying "// Set no expectations but answer a
> value
> for the specified method ". 

Yes, I have read this comment, hence my comment: " It seems to me that
the verify() will trigger a check to verify that the expect*() calls did
actually happen whereas this would not be checked for the match*()
ones". 

My English may seem good but I don't think in the same way as you do
guys so it may take me longer to understand something... please bear
with me ;-)

I'll complement my question: Is expect*() considered deprecated now? But
then, why is it in the example...

> Using ANY_ARGS as parameter constraint will
> give
> you the same behavior as you used to have, however using constraints
can
> give you hashtable like behavior for example.
> 
> We did consider calling this method "stubAndReturn" however Steve felt
it
> didn't indicate the matching of the constraints very well.

Yes, but expect*() also support matching constraints! I'm completely
lost now :-)

> 
> > - I've started looking at the
> > src\examples\com\mockobjects\examples\dynamic\
SimpleServletTest.java
> > example. It doesn't seem to be finished though and is missing some
> > comments. But that would be the best help for those starting with
the
> > new dyna Mock API. Some questions:
> 
> The example is an example of test first programming - e.g. the code
> doesn't
> actually have to work to have all the tests passing. Some of the real
> implementations are left to the reader to implement them.
> 
> >   - I don't understand what's the purpose of the Timer class. Also,
it
> > wasn't in the testDoGetOldStyle() method. I think the Timer is
muddying
> > the example and should be removed altogether (unless there's
something I
> > don't understand!).
> 
> The timer demonstrates an interface of an object that we expect to
return
> multiple results from a single method (the idea being, if we were
going to
> indicate the elapsed time of an operation this is ofent something). I
> would
> say the code in the Servlet gives this impression:
> 
>  	  writer.print("timer before:" + timer.getTime());
>         mailSender.sendMail(subject, recipients, body);
>         writer.print("timer after:" + timer.getTime());
> 

ok, I think I get it now. A comment would be nice to explain this... Am
I allowed to comment it?

> >   - What's the point of using the second parameter (i.e. "response")
in:
> >       new OrderedMock(HttpServletResponse.class, "response");
> 
> As the name of the Parameter, "name" implies, it gives the mock a non
> default name. A simple examination of the code makes this pretty
obvious.

I had looked at the code. Here it is:

public class OrderedMock extends Mock {

	public OrderedMock(Class mockedClass) {
		this(mockedClass, mockNameFromClass(mockedClass));
	}

	public OrderedMock(Class mockedClass, String name) {
		super(new DefaultCallFactory(), new
CallSequence(),mockedClass, name);
	}

}

It doesn't tell anything to me.... and then if you have the time to
follow the code, it calls the following constructor from the Mock class:

	public Mock(CallFactory callFactory, CallableAddable
callableAddable, Class mockedClass, String name) {
		this.name = name;
[...]

Still without any comment!

I would need to browse and scan the full code to understand what it
does...

> As the name of the Parameter, "name" implies, it gives the mock a non
> default name.

I mean I can see that. My question wasn't that. It was: 

> >   - What's the point of using the second parameter (i.e. "response")
in:
> >       new OrderedMock(HttpServletResponse.class, "response");

I can't figure out why we need to use "response" in this test sample! It
doesn't seem to be used anywhere. I mean if we want to show how to use
the second parameter we should demonstrate an example where we need this
second parameter and explain why...

> If
> you have two objects of the same time (e.g. a Customer) - it is useful
if
> the error message is the same for both of them if one is causing the
> failure.
> 

ok, I get it now. Sorry but that wasn't obvious at all and would
definitely require some javadoc or a good test... Problem is that the
test would not show much unless you put comments in it as it is a
runtime stuff...

> As I am sure you are going to ask - MailSender is an example of an
object
> that takes an Object[] as a parameter. In Java its important to get
this
> one
> right so that the error messages are clear.
> 
> >   - At some point, it says: " // Proposed enhancement to allow
> > individual ordering". Is it done? As the http response is an ordered
> > mock, isn't the implemented solution already doing the same as what
is
> > in the comments?
> 
> No - the comment is right, its not implemented yet. MockHttpResponse
> shouldn't actually be totally ordered as not all messages have to be
in a
> specific order, it really should just be a Mock with this type of
code.

Thus, if I understand correctly, there will be 2 solution for sequence
calls:
- use a OrderedMock but then all calls are supposed to be in the same
order as the order in which we define the match*() (or expect*()) calls.
- use expectBefore() when you simply need to order 2 calls

Is that correct?

> 
> > - Is the ConstraintMatcher[] supposed to be used internally or used
by
> > the user? It is not used in the sample servlet test. In other words,
how
> > would you translate the following (old style):
> >
> >         mockRequest.expectVoid("setAttribute", new Constraint[] {
> > C.eq("result"), C.IS_ANYTHING });
> 
> You can instantiate a FullConstraintMatcher if you want e.g.:
>    mockRequest.expect("setAttribute", new
> FullConstraintMatcher(C.eq("result"), C.IS_ANYTHING));
> 
> but simpler still is:
>    mockRequest.expect("setAttribute", C.args(C.eq("result"),
> C.IS_ANYTHING);

ok

Thanks
-Vincent

> 
> > Thanks
> 
> No problem.
> 
> Tim
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003