headers
Martin Kersten | 21 Mar 14:49

[jmock-dev] Naming of expects method

Hi there,

   I was constantly wondering why the Mock.expects method 
is called expects method. 

You know the only guess I have is this:

mock.expects(..) means "the mock expects (...)"

but I would go for:

mock.expect(...) meaning "mock you should expect..."

Another thing that I noticed is, I only use 
mock.expects(once) or mock.stub(..). I guess it would
be nice if a expects() method would be available, which
means exactly the same as expects(once()).

-> expects() <--> expects(once())

I tried this and it improved the readability.

Thanks,

Martin (Kersten)
Permalink | Reply |
headers
steve-/6t1Ty3A97Vaa/9Udqfwiw@public.gmane.org | 21 Mar 14:54
Favicon

Re: [jmock-dev] Naming of expects method


On 21 March, 2005, Martin Kersten wrote:
>    I was constantly wondering why the Mock.expects method 
> is called expects method. 
> 
> You know the only guess I have is this:
> 
> mock.expects(..) means "the mock expects (...)"

exactly. We're trying to give it a declarative field, rather than procedural.

> Another thing that I noticed is, I only use 
> mock.expects(once) or mock.stub(..). I guess it would
> be nice if a expects() method would be available, which
> means exactly the same as expects(once()).
> 
> -> expects() <--> expects(once())

I'm coming round to this one. I've been writing a great deal of expects(once()) recently.

S.
Permalink | Reply |
headers
Martin Kersten | 21 Mar 16:13

Re: [jmock-dev] Naming of expects method

Hi Steve,

>> I was constantly wondering why the Mock.expects method
>> is called expects method.
>>
>> You know the only guess I have is this:
>>
>> mock.expects(..) means "the mock expects (...)"

> exactly. We're trying to give it a declarative field, rather than 
> procedural.

But by using a method, you are using a descriptive language.
I would rather see the mock as being advised to expect a
certain event (method invocation). Therefore I
(as the creator of the test-case) tell the mock about
the expections I have and since it is an active object, I tell
it what to do.

Therefore I consider using the third person verbform
(adding -s) is a description of the state the mock has
during the test-case, but it is not what happends within
the line. I don't want to split hairs, but I like to read
unit-tests the same way I read other code.
I want to read what happens and not what happend.

But maybe I don't know what you mean exactly by referring to
a declarative field. If you have any resources or further
explainations, what a declarative field is and
how it is used (concept), I would be glad to know.
(Continue reading)

Permalink | Reply |
headers
steve-/6t1Ty3A97Vaa/9Udqfwiw@public.gmane.org | 21 Mar 16:28
Favicon

Re: [jmock-dev] Naming of expects method


On 21 March, 2005, Martin Kersten wrote:
> PS: Have you ruled out any oppion about the 6 points I
>       suggested within the user-maillist? 

no. I just haven't had time to work through the message. There was quite a lot to digest :)

S.
Permalink | Reply |
headers
Nathaniel Pryce | 21 Mar 17:06

Re: [jmock-dev] Naming of expects method


We originally called the methods "stub" and "expect" but it just didn't
feel right when reading the tests later.  The point of the tests is to
declare to the reader what is/isn't expected.  The fact that there is some
imperative code under the covers is an implementation detail.

As for expects() being a synonym for the expects(once()) method, I'm not
sure.  When we were writing DynaMock we had a lot of shortcuts and allowed
users to miss out arguments to mean special things. The result was
confusion and misconceptions for everyone concerned.

An essential aspect of Agile development is that code is as easy as
possible to change.  Sometimes that means that it is not as easy to write
the first time as it could be.  The trade off is worth it for anything but
trivial or throwaway code.

--Nat.

-----"Martin Kersten" <Martin.Kersten@...> wrote:
-----

>To:
>From: "Martin Kersten"
>Date: 03/21/2005 01:49PM
>Subject: [jmock-dev] Naming of expects method
>
>Hi there,
>
> I was constantly wondering why the Mock.expects method
>is called expects method.
(Continue reading)

Permalink | Reply |
headers
Martin Kersten | 21 Mar 18:15

Re: [jmock-dev] Naming of expects method

> We originally called the methods "stub" and "expect" but it just didn't
> feel right when reading the tests later.  The point of the tests is to
> declare to the reader what is/isn't expected.  The fact that there is some
> imperative code under the covers is an implementation detail.

Thats why I suggested the following (user-maillist):

imageRegistry.expect("the OUT should request the image xxx")
     .method("getImage").with(eq("imagename")).will(returnValue(image);

This is how I would like things to be. You know I love to use
the message param of the assertXXX statements. So I always wanted
to formulate my expectations using natural language, like I formulate
my assertions.

And by using expects this sounds not natural. I read the method.with
stuff the same way. testCase.asserts().same(bla).

> As for expects() being a synonym for the expects(once()) method, I'm not
> sure.  When we were writing DynaMock we had a lot of shortcuts and allowed
> users to miss out arguments to mean special things. The result was
> confusion and misconceptions for everyone concerned.

> An essential aspect of Agile development is that code is as easy as
> possible to change.  Sometimes that means that it is not as easy to write
> the first time as it could be.  The trade off is worth it for anything but
> trivial or throwaway code.

Sure. But this is sure a weakness of Java. I mean by treating
primitves as non-objects. Ok, now we have autoboxing, but this
(Continue reading)

Permalink | Reply |
headers
Chad Woolley | 23 Mar 20:08

Re: [jmock-dev] Naming of expects method

I like expects(...).  Make the mock definitions read as much like a 
natural english sentence as possible, describing the desired behavior.

Nathaniel Pryce wrote:

> We originally called the methods "stub" and "expect" but it just didn't
> feel right when reading the tests later.  The point of the tests is to
> declare to the reader what is/isn't expected.  The fact that there is some
> imperative code under the covers is an implementation detail.
> 
> As for expects() being a synonym for the expects(once()) method, I'm not
> sure.  When we were writing DynaMock we had a lot of shortcuts and allowed
> users to miss out arguments to mean special things. The result was
> confusion and misconceptions for everyone concerned.
> 
> An essential aspect of Agile development is that code is as easy as
> possible to change.  Sometimes that means that it is not as easy to write
> the first time as it could be.  The trade off is worth it for anything but
> trivial or throwaway code.
> 
> --Nat.
> 
> -----"Martin Kersten" <Martin.Kersten@...> wrote:
> -----
> 
> 
>>To:
>>From: "Martin Kersten"
>>Date: 03/21/2005 01:49PM
>>Subject: [jmock-dev] Naming of expects method
(Continue reading)

Permalink | Reply |
headers
Martin Kersten | 29 Mar 19:09

Re: Naming of expects method

Hi there,

>I like expects(...).  Make the mock definitions read as much like a natural 
>english sentence as possible, describing the desired behavior.

I used the 'expect' to alter some more complex test-setups. I have
to admit that expects sounds more natural.So you are right and
I was wrong *sob* ;-D.

But the expects(String description) proved to be a great helper.
Did anyone tried this, too? Saidly It is not easy to add the provided
description to the verification faults, if you don't want to alter
the jmock library itself.

Cheers,

Martin (Kersten)

PS:
   Is there a preview of jMock 2.0 available (just a snapshot)?
   I would like to take a look at the cast behaviour.

>> We originally called the methods "stub" and "expect" but it just didn't
>> feel right when reading the tests later.  The point of the tests is to
>> declare to the reader what is/isn't expected.  The fact that there is 
>> some
>> imperative code under the covers is an implementation detail.
>>
>> As for expects() being a synonym for the expects(once()) method, I'm not
>> sure.  When we were writing DynaMock we had a lot of shortcuts and
(Continue reading)

Permalink | Reply |
headers
Steve Freeman | 29 Mar 23:41
Favicon

Re: Naming of expects method

Martin Kersten wrote:
>   Is there a preview of jMock 2.0 available (just a snapshot)?
>   I would like to take a look at the cast behaviour.

everything we've done is in CVS. Sadly we haven't as much time as we'd like.

S.
Permalink | Reply |
headers
Nat Pryce | 30 Mar 10:30

Re: Naming of expects method

Not yet.  Have a look at OO-Matron (http://xspecs.sf.net) to see some
ideas that might eventually make their way into jMock, in particular
the lack of the proxy method.  It also lets you -- actually forces you
to -- describe expectations.  However, it's experimental, undocumented
apart from the tests, and somewhat wierd compared to jMock.

--Nat.

On Tue, 29 Mar 2005 19:09:25 +0200, Martin Kersten
<Martin.Kersten@...> wrote:
> Hi there,
> 
> >I like expects(...).  Make the mock definitions read as much like a natural
> >english sentence as possible, describing the desired behavior.
> 
> I used the 'expect' to alter some more complex test-setups. I have
> to admit that expects sounds more natural.So you are right and
> I was wrong *sob* ;-D.
> 
> But the expects(String description) proved to be a great helper.
> Did anyone tried this, too? Saidly It is not easy to add the provided
> description to the verification faults, if you don't want to alter
> the jmock library itself.
> 
> Cheers,
> 
> Martin (Kersten)
> 
> PS:
>   Is there a preview of jMock 2.0 available (just a snapshot)?
(Continue reading)

Permalink | Reply |

Gmane