TypeMock vs. Rhino.Mocks fluent interface

58 views
Skip to first unread message

Stefan Lieser

unread,
Feb 16, 2008, 8:59:08 AM2/16/08
to altnetuk...@googlegroups.com
I started to play with TypeMock and did not find a fluent interface of
the form Rhino.Mocks has it. First it was only a bit of uncomfortable
feeling, later I recognized the missing type safety:

// TypeMock
mock.ExpectAndReturn(customer.Orders, new Order[] { order });

// Rhino.Mocks
Expect.Call(customer.Orders).Return(new Order[] { order });


TypeMock's ExpectAndReturn doesn't use generics, so the return value
(2nd parameter) is of type object. Rhino uses generics, so ReSharper
(and of course the compiler) can infer the type for the "Return" parameter.

Besides feeling a bit uncomfortable with TypeMock's syntax I think it
has a major disadvantage: missing type safety. If I change the type of a
property the Rhino tests break at compile time while the TypeMock test
break at runtime. So my feedback loop is getting longer and thats what
TDD is *not* about.

Did I miss something?


Regards,
Stefan Lieser
--
http://www.lieser-online.de

Roy Osherove

unread,
Feb 16, 2008, 10:28:47 AM2/16/08
to altnetuk...@googlegroups.com
Of course it supports it, using Narutal mocks, or the generic version of Mock and MockObject<T>
You should use TypeMocks NaturalMocks for typesafe and mocking a chain of calls for example

using (RecordExpectation r = new RecordExpectation ())

{

  Factory.GetCustomer().Orders();

   r.Return(fakeOrders);

}



Author of "The Art Of Unit Testing" ( http://ArtOfUnitTesting.com )
www.ISerializable.com (blog)

Stefan Lieser

unread,
Feb 16, 2008, 1:47:50 PM2/16/08
to altnetuk...@googlegroups.com
Roy, I think its time to discuss it on a complete example (see below). I
don't see how to make the call to r.Return(...) compiletime (!)
typesafe. If I change the type of Order.Id from string to int, the test
will compile but break at runtime. With Rhino it breaks at compile time.

Besides the compiletime typesafety I prefer to write the expectations
more fluent like r.CallTo(order.Id).Returns("42), but thats another story.

Please show me how to get this compiletime typesafe.

Regards,
Stefan Lieser


using Microsoft.VisualStudio.TestTools.UnitTesting;
using TypeMock;

namespace TestProject1
{
public class Order
{
public string Id { get; set; }
}

[TestClass]
public class TypeSafeMocking
{
[TestMethod]
public void OrderId() {
Order order = new Order();

using (RecordExpectations r = RecorderManager.StartRecording()) {
var id = order.Id;
r.Return("42");
}

Assert.AreSame("42", order.Id);
}
}
}


Roy Osherove schrieb:


> Of course it supports it, using Narutal mocks, or the generic version of
> Mock and MockObject<T>
> You should use TypeMocks NaturalMocks for typesafe and mocking a chain
> of calls for example
>
> using (RecordExpectation r = new RecordExpectation ())
>
> {
>
> Factory.GetCustomer().Orders();
>
> r.Return(fakeOrders);
>
> }
>
>
>
> On Feb 16, 2008 3:59 PM, Stefan Lieser <ste...@lieser-online.de

> <mailto:ste...@lieser-online.de>> wrote:
>
>
> I started to play with TypeMock and did not find a fluent interface of
> the form Rhino.Mocks has it. First it was only a bit of uncomfortable
> feeling, later I recognized the missing type safety:
>
> // TypeMock
> mock.ExpectAndReturn(customer.Orders, new Order[] { order });
>
> // Rhino.Mocks
> Expect.Call(customer.Orders).Return(new Order[] { order });
>
>
> TypeMock's ExpectAndReturn doesn't use generics, so the return value
> (2nd parameter) is of type object. Rhino uses generics, so ReSharper
> (and of course the compiler) can infer the type for the "Return"
> parameter.
>
> Besides feeling a bit uncomfortable with TypeMock's syntax I think it
> has a major disadvantage: missing type safety. If I change the type of a
> property the Rhino tests break at compile time while the TypeMock test
> break at runtime. So my feedback loop is getting longer and thats what
> TDD is *not* about.
>
> Did I miss something?
>
>
> Regards,
> Stefan Lieser
> --
> http://www.lieser-online.de
>
>
> Author of "The Art Of Unit Testing" ( http://ArtOfUnitTesting.com )

> www.ISerializable.com <http://www.ISerializable.com> (blog)
> >

Roy Osherove

unread,
Feb 16, 2008, 5:28:24 PM2/16/08
to altnetuk...@googlegroups.com, Oren Eini
yep. you're right. that's one area where Typemock is not totally typesafe. perhaps when we drop support for .net 1.1 we can make it so.

Roy Osherove

unread,
Feb 17, 2008, 3:19:31 AM2/17/08
to altnetuk...@googlegroups.com
BTW - how would you do it with Rhinomocks?

--
Thanks,

Roy Osherove
www.TypeMock.com - Simplify Unit Testing

Ayende Rahien

unread,
Feb 17, 2008, 3:31:53 AM2/17/08
to altnetuk...@googlegroups.com
I am not following

Stefan Lieser

unread,
Feb 17, 2008, 4:42:14 AM2/17/08
to altnetuk...@googlegroups.com
Roy Osherove schrieb:

> BTW - how would you do it with Rhinomocks?

With Rhino.Mocks I would do it this way:

[TestMethod]
public void OrderId_Rhino() {
MockRepository mocks = new MockRepository();
Order order = mocks.DynamicMock<Order>();

using (mocks.Record()) {
Expect.Call(order.Id).Return("42");
}

Assert.AreSame("42", order.Id);
}


If I change the type of property Order.Id from string to int without
changing Return("42") to Return(42) the compiler will blame me.


Regards,
Stefan

Roy Osherove

unread,
Feb 17, 2008, 4:47:13 AM2/17/08
to altnetuk...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages