// 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
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)
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)
> >
www.ISerializable.com (blog)
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