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.
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> 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.
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"); }
> 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.
> 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 });
> > 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.
> 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.
> On Feb 16, 2008 8:47 PM, Stefan Lieser <ste...@lieser-online.de> wrote:
> > 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"); > > }
> > 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 });
> > > 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.
> On Feb 17, 2008 12:28 AM, Roy Osherove <r...@osherove.com> wrote:
> > 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.
> > On Feb 16, 2008 8:47 PM, Stefan Lieser <ste...@lieser-online.de> wrote:
> > > 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"); > > > }
> > > 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 });
> > > > 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.
> On 2/17/08, Roy Osherove <r...@osherove.com> wrote:
> > BTW - how would you do it with Rhinomocks?
> > On Feb 17, 2008 12:28 AM, Roy Osherove <r...@osherove.com> wrote:
> > > 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.
> > > On Feb 16, 2008 8:47 PM, Stefan Lieser <ste...@lieser-online.de> > > > wrote:
> > > > 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"); > > > > }
> > > > 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 });
> > > > > 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.
