rmock-users — For questions related to the usage of rMock

AW: [Rmock-users] Argument expectations

[Ziem, T. <Tho...@t-...>]

Hi Joakim,

I also think that your first approach is needed for the cases you have =
described.
The second approach is not really needed in my opinion (please correct =
me if I'm wrong).
It depends on your internal expectation processing. I assume that you =
have an ordered list in which all expectations are stored. If you will =
check the matching of an expectation in the reverse order (last in - =
first out), I think you don't need the described extension over =
precedes().

Regards,
Thomas


> -----Urspr=FCngliche Nachricht-----
> Von: Joakim Ohlrogge [mailto:joa...@gm...]=20
> Gesendet: Dienstag, 24. Januar 2006 10:57
> An: Ziem, Thomas
> Cc: rmo...@li...
> Betreff: Re: [Rmock-users] Argument expectations
>=20
>=20
> Hi Thomas,
>=20
> I have to give this some more thought but I think here is=20
> what it would probably look like in rMock (input for brainstorming):
>=20
> protected void setUp() throws Exception {
>    super.setUp();
>    _mock =3D mock(MyObject.class, "mock");
>    _mock.method1("");
>   =20
> modify.overidable("id").multiplicity(expect.atLeast(0)).args(i
> s.ANYTHING);
> }
>=20
> public void testMethod1() {
>    _mock.method1("aaa");
>    modify.overrides("id").returnValue("bbb"); // replaces the=20
> overideable id expectation
>=20
>    _mock.method1("ccc");  // a new expectation like any other
>    modify.returnValue("ddd");
>=20
>    _mock.method1("");
>    modify.multiplicity(expect.atLeast(0)).args(is.ANYTHING);=20
> // reintroduce an expect anything, that matches everyting not=20
> matched by the previous two
>=20
>    startVerification();
>=20
>    assertThat(_mock.method1("xxx"), is.NULL);
>    assertThat(_mock.method1("aaa"), is.eq("bbb"));
>    assertThat(_mock.method1("ccc"), is.eq("ddd"));
> }
>=20
> This looks slightly different from what you suggested but I=20
> feel that the id is needed if you are using sections (like=20
> some of your expectations are within an ordered section or=20
> you want the matches to be more restrictive like replacing=20
> args(is.ANYTHING) with
> args(is.eq("hi").or(is.eq("bye")) ). Also in my example the=20
> overiding expectation simply replaces the "default" one. In=20
> your example it precedes the expectation, both sort of make=20
> sense in different ways.
>=20
> Another approach more similar to what you suggested might=20
> also be feasable, and that is to "precede" the named=20
> expectation, which would be the same as declaring other=20
> expectations in front of it... sort of grouping them together:
>=20
>=20
> protected void setUp() throws Exception {
>    super.setUp();
>    _mock =3D mock(MyObject.class, "mock");
>    _mock.method1("");
>   =20
> modify.overidable("id").multiplicity(expect.atLeast(0)).args(i
> s.ANYTHING);
> }
>=20
> public void testMethod1() {
>    _mock.method1("aaa");
>    modify.precedes("id").returnValue("bbb"); // precedes the=20
> overideable id expectation
>=20
>    _mock.method1("ccc");  // a new expectation like any other
>    modify.precedes(id).returnValue("ddd");  // precedes the=20
> overideable id expectation but succedes "aaa"
>=20
>    startVerification();
>=20
>    assertThat(_mock.method1("xxx"), is.NULL);
>    assertThat(_mock.method1("aaa"), is.eq("bbb"));
>    assertThat(_mock.method1("ccc"), is.eq("ddd"));
> }
>=20
>=20
> rmock would see both examples as:
>=20
>    _mock.method1("aaa");
>    modify.returnValue("bbb");
>=20
>    _mock.method1("ccc");  // a new expectation like any other
>    modify.returnValue("ddd");
>=20
>    _mock.method1("");
>    modify.multiplicity(expect.atLeast(0)).args(is.ANYTHING);
>=20
>=20
>=20
> I'm not sure what I prefer or if both or none should be=20
> supported or if there are better solutions to this. You=20
> always have the opprotunity to create several fixtures but I=20
> can see a value in having a general setup and replace an 
> expectation or two from a common fixture in one or two tests=20
> but I see it as a tradeoff since it obscures the tests=20
> slightly. I am a bit concerned about the suffering of rMocks,=20
> top-down readability but it might be that I am not used to=20
> this idea yet.
>=20
> What do you think, would either of those solutions be helpful to you?
>=20
> Regards
> /Joakim
>=20

Re: [Rmock-users] Argument expectations

[Joakim O. <joa...@gm...>]

Hi Thomas,

I have to give this some more thought but I think here is what it
would probably look like in rMock (input for brainstorming):

protected void setUp() throws Exception {
   super.setUp();
   _mock =3D mock(MyObject.class, "mock");
   _mock.method1("");
   modify.overidable("id").multiplicity(expect.atLeast(0)).args(is.ANYTHING=
);
}

public void testMethod1() {
   _mock.method1("aaa");
   modify.overrides("id").returnValue("bbb"); // replaces the
overideable id expectation

   _mock.method1("ccc");  // a new expectation like any other
   modify.returnValue("ddd");

   _mock.method1("");
   modify.multiplicity(expect.atLeast(0)).args(is.ANYTHING); //
reintroduce an expect anything, that matches everyting not matched by
the previous two

   startVerification();

   assertThat(_mock.method1("xxx"), is.NULL);
   assertThat(_mock.method1("aaa"), is.eq("bbb"));
   assertThat(_mock.method1("ccc"), is.eq("ddd"));
}

This looks slightly different from what you suggested but I feel that
the id is needed if you are using sections (like some of your
expectations are within an ordered section or you want the matches to
be more restrictive like replacing args(is.ANYTHING) with
args(is.eq("hi").or(is.eq("bye")) ). Also in my example the overiding
expectation simply replaces the "default" one.
In your example it precedes the expectation, both sort of make sense
in different ways.

Another approach more similar to what you suggested might also be
feasable, and that is to "precede" the named expectation, which would
be the same as declaring other expectations in front of it... sort of
grouping them together:


protected void setUp() throws Exception {
   super.setUp();
   _mock =3D mock(MyObject.class, "mock");
   _mock.method1("");
   modify.overidable("id").multiplicity(expect.atLeast(0)).args(is.ANYTHING=
);
}

public void testMethod1() {
   _mock.method1("aaa");
   modify.precedes("id").returnValue("bbb"); // precedes the
overideable id expectation

   _mock.method1("ccc");  // a new expectation like any other
   modify.precedes(id).returnValue("ddd");  // precedes the
overideable id expectation but succedes "aaa"

   startVerification();

   assertThat(_mock.method1("xxx"), is.NULL);
   assertThat(_mock.method1("aaa"), is.eq("bbb"));
   assertThat(_mock.method1("ccc"), is.eq("ddd"));
}


rmock would see both examples as:

   _mock.method1("aaa");
   modify.returnValue("bbb");

   _mock.method1("ccc");  // a new expectation like any other
   modify.returnValue("ddd");

   _mock.method1("");
   modify.multiplicity(expect.atLeast(0)).args(is.ANYTHING);



I'm not sure what I prefer or if both or none should be supported or
if there are better solutions to this. You always have the opprotunity
to create several fixtures but I can see a value in having a general
setup and replace an expectation or two from a common fixture in one
or two tests but I see it as a tradeoff since it obscures the tests
slightly. I am a bit concerned about the suffering of rMocks, top-down
readability but it might be that I am not used to this idea yet.

What do you think, would either of those solutions be helpful to you?

Regards
/Joakim

Re: [Rmock-users] Argument expectations

[Ziem, T. <Tho...@t-...>]

Hi Joakim,

thank you for your answer.
I think support of overriding would be very helpful.

Here my use case:

protected void setUp() throws Exception {
    super.setUp();
    _mock =3D mock(MyObject.class, "mock");
    _mock.method1("");
    modify.multiplicity(expect.atLeast(0)).args(is.ANYTHING);
}

public void testMethod1() {
    _mock.method1("aaa");
    modify.returnValue("bbb");

    _mock.method1("ccc");
    modify.returnValue("ddd");

    startVerification();

    assertThat(_mock.method1("xxx"), is.NULL);
    assertThat(_mock.method1("aaa"), is.eq("bbb"));
    assertThat(_mock.method1("ccc"), is.eq("ddd"));
}

If I put the expectation of setUp() into testMethod1() right before =
startVerification() than it will work.

Regards,
Thomas



> -----Urspr=FCngliche Nachricht-----
> Von: rmo...@li...=20
> [mailto:rmo...@li...] Im Auftrag=20
> von Joakim Ohlrogge
> Gesendet: Montag, 23. Januar 2006 10:33
> An: rmo...@li...
> Betreff: Re: [Rmock-users] Argument expectations
>=20
>=20
> Hi Thomas and welcome to the list.
>=20
> I had to update myself on the stubs() functionalitz of jMock=20
> and we you do something similar in rMock (assuming i=20
> understood the stub() method correctly in jMock):
>=20
> MyObject mock =3D mock(MyObject.class, "mock");
>=20
> mock.method1("arg");
> modify.multiplicity(expect.atLeast(0)).args(is.ANYTHING);
>=20
>=20
> This will create a 0..* expecation. What is not currently=20
> supported though is to override it in your test. That is, you=20
> cannot change the expectation to atLeastOnce() in a=20
> testMethod, it will continue to be optional.
>=20
> I would be happy to help out and implement something to make=20
> it overridable in the future but as it is now you can only=20
> specify that you don't really care about some methods in a=20
> fixture, if you care about it in some tests then that=20
> requires different fixtures.
>=20
> Cheers!
> /Joakim
>=20
>=20
> On 1/23/06, Ziem, Thomas <Tho...@t-...> wrote:
> > Hi everyone,
> >
> > is it possible to define some generic argument expectations=20
> like it is=20
> > done in jMock:
> >
> > Mock oMock =3D new Mock(MyInterface.class);
> >
> > oMock.stubs()
> >      .method("method1")
> >      .withAnyArguments()
> >      .will(returnValue(null));
> >
> > Thanks,
> > Thomas
> >
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep=20
> through log files for problems?  Stop!  Download the new AJAX=20
> search engine that makes searching your log files as easy as=20
> surfing the  web.  DOWNLOAD SPLUNK!=20
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&
dat=3D121642
_______________________________________________
Rmock-users mailing list
Rmo...@li... =
https://lists.sourceforge.net/lists/listinfo/rmock-users

Re: [Rmock-users] Argument expectations

[Joakim O. <joa...@gm...>]

Hi Thomas and welcome to the list.

I had to update myself on the stubs() functionalitz of jMock and we
you do something similar in rMock (assuming i understood the stub()
method correctly in jMock):

MyObject mock =3D mock(MyObject.class, "mock");

mock.method1("arg");
modify.multiplicity(expect.atLeast(0)).args(is.ANYTHING);


This will create a 0..* expecation. What is not currently supported
though is to override it in your test. That is, you cannot change the
expectation to atLeastOnce() in a testMethod, it will continue to be
optional.

I would be happy to help out and implement something to make it
overridable in the future but as it is now you can only specify that
you don't really care about some methods in a fixture, if you care
about it in some tests then that requires different fixtures.

Cheers!
/Joakim


On 1/23/06, Ziem, Thomas <Tho...@t-...> wrote:
> Hi everyone,
>
> is it possible to define some generic argument expectations like it is do=
ne in jMock:
>
> Mock oMock =3D new Mock(MyInterface.class);
>
> oMock.stubs()
>      .method("method1")
>      .withAnyArguments()
>      .will(returnValue(null));
>
> Thanks,
> Thomas
>

[Rmock-users] Argument expectations

[Ziem, T. <Tho...@t-...>]

Hi everyone,

is it possible to define some generic argument expectations like it is done in jMock:

Mock oMock = new Mock(MyInterface.class);

oMock.stubs()
     .method("method1")
     .withAnyArguments()
     .will(returnValue(null));

Thanks,
Thomas

[Rmock-users] rmock-2.0.0-rc-3

[Daniel B. <dan...@gm...>]

Hello!
We've just released a new version of rMock. Please, check out the site
for more detail.

If you have any questions on how to use rMock, observations of things
that works in strange ways or just plain ol' feature requests, please
post them here or on the site and we'd be happy to try our best to
help you out!

Cheers
Daniel


--
__________________________
Dan...@Gm...

[Rmock-users] rMock 2.0.0 beta-5 released

[Daniel B. <dan...@gm...>]

Another week, another release.

The work this last week has been focused on updating rMock to support
the documentation-generating sister-project rDoc (available in CVS
only), so there are no new "visible" features this week. In rDoc, we
have been able to generate sequence diagrams from invocation events
from the mocked, stubbed and monitored objects. The diagrams are still
not presentable, but we hope to get there soon, partly with the
AspectJ proxy factory.

The coming week we hope to

* Rework the ExpectationGenerator (rMock)
* Improve our documentation generation (rDoc).
* Add a comparison between rMock, EasyMock and jMock for our potential
users to make a more informed decision on choosing mock framework
(rMock)
* Add support to have singleton services on the hub (rMock)
* Begin working on the AspectJ proxy factory (rMock)

You might wonder what is keeping us from making a "real" release (i.e.
not alpha, beta, rc etc).
The reason is that, as we see rMock, there are mainly two parts:
1) The mock framework with asserts and setups etc
2) The plugin model and the message hub

We don't expect 1) to change much. We will add features along the way,
e.g. more specialized constraints, but the core mocking API won't
change under 2.x. What might still change is 2). We are getting there,
but we still discover things that changes too big a parts of the
message hub and plugin model to have it in a stable release. At the
moment, we who develop rMock are the only ones concerned with that,
but eventually we hope that third party providers will extend rMock
with new features using the hub.

Cheers
Daniel and the rMock team
--
__________________________
Dan...@Gm...

[Rmock-users] rMock beta-4 release

[Joakim O. <joa...@gm...>]

Another weekly release of rMock has just been made: beta-4

Changes since last week

The main visible contribution this week was the expectation generator
(see link "Getting started" in left navigation). To support it we
have added begins-with and ends-with constraints to the
ConstraintFactory (the "is" reference in RMockTestCase).
Under the hood we are still working on the documentation features,
refactoring the framework to suit the documentation needs.
We hope to be able to pull together the first generated documentation
(including a rudimentary sequence diagram) during the next week.

Cheers
The rMock team

[Rmock-users] rMock 2.0.0 Beta 3 released

[Daniel B. <dan...@gm...>]

Hi everybody!
The beta 3 version of rMock is out.

This week we added some new factory methods on the constraint factory,
improved the array comparison and messaging functionality and made
some internal refactorings.

The next week we hope to get a shot at the documenting features.

If you have any questions about rMock, please post them here. We want
your input and questions to improve the framework!

Regards
Daniel Brolund

[Rmock-users] rMock 2.0.0-beta-2 released!

[Daniel B. <dan...@gm...>]

rMock 2.0.0-beta-2 released!

The rMock team is proud to present the beta-2 version of rMock 2.0.0
as part of the weekly release heartbeat.

The focus for the last week was to get the first version of the
message bus in place.

No changes to the api was needed this time, and since no bugs were
found no bugs were fixed.

We will continue the work on the message bus and the documentation
features of rMock in the newly created module rDoc (only in cvs at the
moment). The plan is to integrate that module as a plugin into rMock
to enable automated, up-to-date project documentation with minimal
effort cost.

Changes:
No API changes this time.
* Added first version of message bus
* Created rDoc project for documenting testcases
* Created TestCaseEventSource, InvocationEventSource and an
ExpectationEventSource and added it to the message bus. Created a
corresponding TestCaseListener, InvocationListener and an
ExpectationListener to use with the event source over the message bus.

/Daniel Brolund on behalf of the rMock team

P.S. Please report any issues, feature requests, documentation
requests or bugs to us and we will address it a.s.a.p., normally in
the next release. We don't need you to be formal in any way, just drop
a line or two on this list or to one of the rMock team members.
--
__________________________
Dan...@Gm...

[Rmock-users] rMock 2.0.0-beta-2 released

[Daniel B. <dan...@gm...>]

rMock 2.0.0-beta-2 released!

The rMock team is proud to present the beta-2 version of rMock 2.0.0
as part of the weekly release heartbeat.

The focus for the last week was to get the first version of the
message bus in place.

No changes to the api was needed this time, and since no bugs were
found no bugs were fixed.

We will continue the work on the message bus and the documentation
features of rMock in the newly created module rDoc (only in cvs at the
moment). The plan is to integrate that module as a plugin into rMock
to enable automated, up-to-date project documentation with minimal
effort cost.

Changes:
No API changes this time.
* Added first version of message bus
* Created rDoc project for documenting testcases
* Created TestCaseEventSource, InvocationEventSource and an
ExpectationEventSource and added it to the message bus. Created a
corresponding TestCaseListener, InvocationListener and an
ExpectationListener to use with the event source over the message bus.

/Daniel Brolund on behalf of the rMock team

P.S. Please report any issues, feature requests, documentation
requests or bugs to us and we will address it a.s.a.p., normally in
the next release. We don't need you to be formal in any way, just drop
a line or two on this list or to one of the rMock team members.