> 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)