Menu
▾
▴
mockobjects-java-dev
|
From: Vincent M. <vm...@pi...> - 2003-05-12 17:37:38
|
Hi,
I've started migrating my existing project to the new Dynamic Mock API
and I have the following questions (maybe this could be the start of a
migration guide or user guide?):
- what is now replacing the setupDefaultResult() method?
Ex: mockRequest.setupDefaultResult(String.class, null);
- 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?
- 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:
- 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!).
- What's the point of using the second parameter (i.e. "response") in:
new OrderedMock(HttpServletResponse.class, "response");
- 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?
- 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 });
Thanks
-Vincent
|
|
From: Steve F. <st...@m3...> - 2003-05-12 21:25:05
|
Vincent Massol wrote: > I've started migrating my existing project to the new Dynamic Mock API > and I have the following questions (maybe this could be the start of a > migration guide or user guide?): > > - what is now replacing the setupDefaultResult() method? > Ex: mockRequest.setupDefaultResult(String.class, null); > > - 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? match tells the mock to return a result when it, um, matches a given call. It's a bit more flexible than the old return code. Presumably matching ANY would count as a default result although I don't think we've tried that. Tim, can you answer the rest? S. |
|
From: Vincent M. <vm...@pi...> - 2003-05-13 07:26:19
|
> -----Original Message----- > From: Steve Freeman [mailto:st...@m3...] > Sent: 12 May 2003 23:25 > To: Vincent Massol > Cc: 'Mockobjects-Java-Dev' > Subject: Re: [MO-java-dev] First batch of questions on new Dynamic Mock > API > > Vincent Massol wrote: > > I've started migrating my existing project to the new Dynamic Mock API > > and I have the following questions (maybe this could be the start of a > > migration guide or user guide?): > > > > - what is now replacing the setupDefaultResult() method? > > Ex: mockRequest.setupDefaultResult(String.class, null); > > > > - 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? > > match tells the mock to return a result when it, um, matches a given > call. It's a bit more flexible than the old return code. Presumably > matching ANY would count as a default result although I don't think > we've tried that. Ok thanks. Then I don't understand the difference between match*() and expectAndReturn(). -Vincent > > > Tim, can you answer the rest? > > S. |
|
From: Tim M. <tim...@po...> - 2003-05-13 23:45:37
|
> Ok thanks. Then I don't understand the difference between match*() and > expectAndReturn(). > This appears to be a stumbling block - its exactly what steve said.. but to repeat: expect means: "To consider obligatory; require: e.g. The school expects its pupils to be on time." match means: "One that is like another in one or more specified qualities: He is John's match for bravery." Thus - expectAndReturn means that it is obligatory for a certain call to happen. We specify that call (becuase java does method overloading). And we also specify the result of that call. matchAndReturn means that we just specify a value that is like what would happen if the real call had taken place. Note that we DONT set any expectation. If the call doesn't happen then no failure would happen. In other words, its a return without any expectation, however in Java you cannot create a method called "return(String name, Object return value)" as return is a reserved word. I can't think of any clearer way of saying this - does it help? 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 |
|
From: Vincent M. <vm...@pi...> - 2003-05-14 07:35:44
|
> -----Original Message----- > From: Tim Mackinnon [mailto:tim...@po...] > Sent: 14 May 2003 01:49 > To: Vincent Massol; 'Steve Freeman' > Cc: 'Mockobjects-Java-Dev' > Subject: RE: [MO-java-dev] First batch of questions on new Dynamic Mock > API > > > > Ok thanks. Then I don't understand the difference between match*() and > > expectAndReturn(). > > > > This appears to be a stumbling block - its exactly what steve said.. but > to > repeat: > > expect means: "To consider obligatory; require: e.g. The school expects > its > pupils to be on time." > match means: "One that is like another in one or more specified qualities: > He is John's match for bravery." > > > Thus - expectAndReturn means that it is obligatory for a certain call to > happen. We specify that call (becuase java does method overloading). And > we > also specify the result of that call. > > matchAndReturn means that we just specify a value that is like what would > happen if the real call had taken place. Note that we DONT set any > expectation. If the call doesn't happen then no failure would happen. > > In other words, its a return without any expectation, however in Java you > cannot create a method called "return(String name, Object return value)" > as > return is a reserved word. > > I can't think of any clearer way of saying this - does it help? It does... It would have been faster for you to just say "yes" to my question... :-). For example: Vincent: "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?" Tim: "Yes, Vincent, that's correct" Thanks for your patience Tim! :-) -Vincent |
|
From: Tim M. <tim...@po...> - 2003-05-12 23:47:13
|
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.
> - what is now replacing the setupDefaultResult() method?
> Ex: mockRequest.setupDefaultResult(String.class, null);
>
> - 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. There is a
comment above these lines saying "// Set no expectations but answer a value
for the specified method ". 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.
> - 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());
> - 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. 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.
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.
> - 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);
> 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
|
|
From: Vincent M. <vm...@pi...> - 2003-05-13 07:48:05
|
> -----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
|
|
From: Tim M. <tim...@po...> - 2003-05-14 00:14:01
|
> -----Original Message-----
> From: Vincent Massol [mailto:vm...@pi...]
> > > - what is now replacing the setupDefaultResult() method?
> > > Ex: mockRequest.setupDefaultResult(String.class, null);
>
> Any answer for that?
Yes: use matchAndReturn("methodName", C.isA(String.class), null)
> 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 ;-)
This has been answered in a previous email which defines expect and match.
> I'll complement my question: Is expect*() considered deprecated now? But
> then, why is it in the example...
expect is Not deprecated, see the previous email
> ok, I think I get it now. A comment would be nice to explain this... Am
> I allowed to comment it?
I will admit that without more context it can be tricky - why not change the
1000 and 2000 numbers to constants that would express this without a
comment? Go on - try doing something to the Test that would make you happy
without a comment?
> 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...
Come on Vincent - you are a better programmer than that - what do you think
the method "mockNameFromClass(mockedClass)" does????? Especially when it
calls a method which when I hover over in my idea pops up a window that
says: "com....Mock(Class mockedClass, String name)"
This doesn't need a comment!!!!! That took all of 15 seconds. In fact less
as when choosing the constructor my IDE shows me the method signature for
both. HOWEVER - having written this, I could improve the variable name, to
nonDefaultName, which I have just done.
>
> > 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...
Actually - I can improve that too, is "response that servlet writes to" a
better example of something you might want to do so that you would get a
better error description? Unfortunately its on the todo list to have a
little App that generates all error messages to the console so that we can
see them and understand the errors better.
> 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?
Exactly! Others have proposed that with this primitive we can do some other
stuff but thats later.
I think we finally got to the bottom of the stuff now - and I hope this has
helped get a better description for your book.
---
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
|
|
From: Vincent M. <vm...@pi...> - 2003-05-14 07:46:18
|
> -----Original Message----- > From: Tim Mackinnon [mailto:tim...@po...] > Sent: 14 May 2003 02:18 > To: Vincent Massol; 'Mockobjects-Java-Dev' > Subject: RE: [MO-java-dev] First batch of questions on new Dynamic Mock > API > [snip] > > I think we finally got to the bottom of the stuff now - and I hope this > has > helped get a better description for your book. It has. Thanks a lot! I still maintain that the issue #1 with MockObjects.com is documentation... :-) Tim, I can assure you not everyone is used to reading the source code when using a third-party framework. I'm currently working on a project and the main issue to using MockObjects.com is documentation. I can't fire the 80+ developers telling them that they are not good enough... (Maybe 2 or 3 would be 1/ able to follow and understand the source code and 2/ willing to do so). Thus, the project manager has tasked me to write the missing MockObjects.com missing documentation for our project... *sigh* I have been postponing this as I also don't like to write doc and I have better things to do... This is just an example to show you that *from the outside* the MockObjects.com suffers from documentation. -Vincent |
|
From: Steve F. <st...@m3...> - 2003-05-15 02:00:06
|
Vincent Massol wrote: > and 2/ willing to do so). Thus, the project manager has tasked me to > write the missing MockObjects.com missing documentation for our > project... *sigh* I have been postponing this as I also don't like to > write doc and I have better things to do... This is just an example to > show you that *from the outside* the MockObjects.com suffers from > documentation. OK. Let's collaborate. Can you outline what you think your developers will need? S. |
|
From: Vincent M. <vm...@pi...> - 2003-05-15 09:01:09
|
> -----Original Message----- > From: Steve Freeman [mailto:st...@m3...] > Sent: 15 May 2003 04:00 > To: Vincent Massol > Cc: 'Tim Mackinnon'; 'Mockobjects-Java-Dev' > Subject: Re: [MO-java-dev] First batch of questions on new Dynamic Mock > API > > Vincent Massol wrote: > > and 2/ willing to do so). Thus, the project manager has tasked me to > > write the missing MockObjects.com missing documentation for our > > project... *sigh* I have been postponing this as I also don't like to > > write doc and I have better things to do... This is just an example to > > show you that *from the outside* the MockObjects.com suffers from > > documentation. > > OK. Let's collaborate. Can you outline what you think your developers > will need? Cool. Thanks! ATM I'm on holiday working on my book but I'll give you more details once I'm back to work (in about 5 days). Thanks -Vincent > > S. > |
|
From: Vincent M. <vm...@pi...> - 2003-05-14 07:50:14
|
> -----Original Message-----
> From: Tim Mackinnon [mailto:tim...@po...]
> Sent: 14 May 2003 02:18
> To: Vincent Massol; 'Mockobjects-Java-Dev'
> Subject: RE: [MO-java-dev] First batch of questions on new Dynamic
Mock
> API
>
>
[snip]
> > > > - what is now replacing the setupDefaultResult() method?
> > > > Ex: mockRequest.setupDefaultResult(String.class, null);
> >
> > Any answer for that?
>
> Yes: use matchAndReturn("methodName", C.isA(String.class), null)
Does it mean the DynaMock API is not offering anymore default behaviors
and that each and single method call has to be matched or expected? Not
that I'm finding that bad, just asking...
Thanks
-Vincent
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X