headers
David Saff | 1 May 2006 05:40
Picon
Favicon

Re: stronger typing

Steve Freeman wrote:
> On 26 Apr 2006, at 14:29, Joris Schouteden wrote:
>> In our project, we use jMock but the adoption is somewhat hindered by 
>> the
>> lack of typing and hence refactoring support.
>
> Is this because it's really getting in the way, or because people 
> don't like it. If the former, your objects may be getting too big.

I could see that needing to frequently rename a frequently-mocked method 
would indicate an over-reliance on a particular interface.  But the 
conceptual leap to objects getting too big doesn't come naturally to me.

There's other reasons than refactoring to like the typesafe approach, 
auto-complete and quick fixing among them.

>> So I created a little extension to jMock that does something similar to
>> what RMock or EasyMock do: allow expectation to be set on the proxy by
>> invoking its methods with the expected arguments.  See below for 
>> examples.
>>
>> So, my questions to jMock development are:
>> - Is there any such functionality planned for jMock?
>
> there's certainly nothing planned.

That sounds less intrigued than Nat's response in the "Typesafe 
expectations" thread from February/March.  Joris, how would you contrast 
your approach to the one outlined in that thread?
(Continue reading)

Permalink | Reply | 5 comments |
headers
Steve Freeman | 1 May 2006 10:54
Picon

Re: stronger typing

On 1 May 2006, at 04:40, David Saff wrote:
> Steve Freeman wrote:
>> On 26 Apr 2006, at 14:29, Joris Schouteden wrote:
>>> In our project, we use jMock but the adoption is somewhat  
>>> hindered by the
>>> lack of typing and hence refactoring support.
>>
>> Is this because it's really getting in the way, or because people  
>> don't like it. If the former, your objects may be getting too big.
>
> I could see that needing to frequently rename a frequently-mocked  
> method would indicate an over-reliance on a particular interface.   
> But the conceptual leap to objects getting too big doesn't come  
> naturally to me.
> There's other reasons than refactoring to like the typesafe  
> approach, auto-complete and quick fixing among them.

It's just that I've found that the lack of IDE support is less of an  
issue when I have many smaller objects, changes become local and  
quick to adjust. Of course, it's not the right thing.

As someone noted on the list, they actually like Strings because it  
means they don't have to keep the compiler happy while they're still  
thinking.

>>> So, my questions to jMock development are:
>>> - Is there any such functionality planned for jMock?
>>
>> there's certainly nothing planned.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Xavier Outhier | 3 May 2006 12:36
Picon

Mocking classes with parameters in construtor: is it possible?

Hi all,

I've just downloaded jMock with the CGLIB extension to mock classes.
I'm not able to create a mock of a class which constructore takes 2
parameters as it seems possible when looking at the page
http://www.jmock.org/cglib.html
"Your tests can now create mocks of abstract or concrete classes:

   1.

Mock mockGraphics = mock(java.awt.Graphics.class,"mockGraphics");

      You can pass arguments to the constructor by passing the argument
      types and values to the |mock| method:

Mock mockedClass = mock(SomeClass.class,"mockList",
                        new Class[]{String.class, int.class},
                        new Object[]{"Hello", new Integer(1)});"

It seems there is no public Mock mock(Class class1, String s, Class[],
Object[])
in org.jmock.Mock not in org.jmock.cglib.MockObjectTestCase.

Do  I do something wrong? Bad versions? Bad usage?
Or is it impossible to mock classes with constructor with parameters?

Cheers,

Xavier.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nat Pryce | 4 May 2006 12:08
Picon

Re: stronger typing

I'm intrigued by Typesafe expectations but jMock will never have a
record/playback style API.  I find it error prone and that it makes
tests hard to understand.  In contrast to Easymock, jMock has a
specification style of API.  You specify what you expect, then run
some code and the mocks will fail the test if what you specified
doesn't happen.  You don't have to switch mocks between modes.

Over the project we've tried various approaches to write a typesafe,
specification style API and have never quite managed to fight our way
past Java's limitations.  We'd love to hear any ideas on how to do
this.

--Nat.

On 5/1/06, David Saff <saff@...> wrote:
> Steve Freeman wrote:
> > On 26 Apr 2006, at 14:29, Joris Schouteden wrote:
> >> In our project, we use jMock but the adoption is somewhat hindered by
> >> the
> >> lack of typing and hence refactoring support.
> >
> > Is this because it's really getting in the way, or because people
> > don't like it. If the former, your objects may be getting too big.
>
> I could see that needing to frequently rename a frequently-mocked method
> would indicate an over-reliance on a particular interface.  But the
> conceptual leap to objects getting too big doesn't come naturally to me.
>
> There's other reasons than refactoring to like the typesafe approach,
> auto-complete and quick fixing among them.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Nat Pryce | 4 May 2006 12:09
Picon

Re: Mocking classes with parameters in construtor: is it possible?

Try the latest RC1 release.

--Nat.

On 5/3/06, Xavier Outhier <xavier.outhier@...> wrote:
> Hi all,
>
> I've just downloaded jMock with the CGLIB extension to mock classes.
> I'm not able to create a mock of a class which constructore takes 2
> parameters as it seems possible when looking at the page
> http://www.jmock.org/cglib.html
> "Your tests can now create mocks of abstract or concrete classes:
>
>    1.
>
> Mock mockGraphics = mock(java.awt.Graphics.class,"mockGraphics");
>
>       You can pass arguments to the constructor by passing the argument
>       types and values to the |mock| method:
>
> Mock mockedClass = mock(SomeClass.class,"mockList",
>                         new Class[]{String.class, int.class},
>                         new Object[]{"Hello", new Integer(1)});"
>
>
> It seems there is no public Mock mock(Class class1, String s, Class[],
> Object[])
> in org.jmock.Mock not in org.jmock.cglib.MockObjectTestCase.
>
> Do  I do something wrong? Bad versions? Bad usage?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joris Schouteden | 4 May 2006 13:29
Picon

Re: stronger typing

Hi,

> record/playback style API.  I find it error prone and that it makes
> tests hard to understand.

It's maybe a bit trickier since you can forget the play() or
startVerification() call, but your test will immediately fail..

Personally (and a lot of my collegues agree), I find string based
expectations a lot more error prone..  In fact, it is _the_ reason why we
are currently looking at other frameworks.

I agree two states in the mock object is ugly, a solution could be to
expose two proxies in the mock, one to be used in the test as usual, the
other to set expectations on:

    public T proxy();
    public T proxyForExpectations();

>> That sounds less intrigued than Nat's response in the "Typesafe
>> expectations" thread from February/March.  Joris, how would you contrast
>> your approach to the one outlined in that thread?

It doesn't look that much different, in fact I see mainly syntactical
differences between the way of working of this, easymock, rmock, jmock
etc..
Just different ways to overcome the java limitations Nat talked about and
make it as easy/compact as possible for the user.

Anyway, I've attached my jmock extension together with it's test and an
(Continue reading)

Permalink | Reply | 2 comments |
headers
Nat Pryce | 4 May 2006 13:35
Picon

Re: stronger typing

We're planning to do away with the proxy altogether, so two proxies
won't work in the future.

Ideally I'd like something like this.

Required required = mocks.newMock(Required.class);

Tested tested = new Tested(required);

mocks.specify(new Once() {
    public void inAnyOrder() {
        required.doSomething("an actual argument"); returnValue(10);
        required.doSomethingElse(eq(10), not(NULL));
    }
});

It's all a bit messy though.

--Nat.

--Nat.

On 5/4/06, Joris Schouteden <joris@...> wrote:
> Hi,
>
> > record/playback style API.  I find it error prone and that it makes
> > tests hard to understand.
>
> It's maybe a bit trickier since you can forget the play() or
> startVerification() call, but your test will immediately fail..
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joris Schouteden | 4 May 2006 13:38
Picon

Re: stronger typing


Hi,

> Ideally I'd like something like this.

Ic..  That would indeed be nice, if maybe a bit verbose.

> Anyway, I've attached my jmock extension

Apparently two of the attachments got lost, so here's everything in one zip.

Joris
Attachment (SemiTypedMock.zip): application/zip, 3921 bytes
Permalink | Reply | 0 comments |
headers
Ben Teese | 5 May 2006 00:53

Re: stronger typing

> Personally (and a lot of my collegues agree), I find string based
> expectations a lot more error prone..  In fact, it is _the_ reason why we
> are currently looking at other frameworks.

+1

Regards,

Ben Teese

Ben Teese
Shine Technologies
http://www.shinetech.com
Permalink | Reply | 0 comments |
headers
J. B. Rainsberger | 10 May 2006 03:23
Favicon

Re: agile 2006 test makeover

Rex Madden wrote:
> http://www.testing.com/cgi-bin/blog/2006/04/06#xtm
> 
> I'm not sure if any of the experts use mock objects.  It would be nice 
> if mocks were represented in some way.

I plan to be one of the experts involved, and I most certainly use mock 
objects.
--

-- 
J. B. (Joe) Rainsberger :: http://www.jbrains.info
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice
Permalink | Reply | 0 comments |

Gmane