Unit Testing, Agile Development, Leadership & .NET - By Roy Osherove
Pingback from Reflective Perspective - Chris Alcock » The Morning Brew #214
Struggling to find a reason that you would use this in a real situation, especially as it will obfuscate your tests (making readers work out which object the method call will be on).
Colin,
it can help immensely to achieve simpler code in some cases. You want to have your own stub class that you manually created, that will be used throughout your test projects.
instead of creating lots of "whenCalled" on some class and returning fake values, you simply swap a class implementation with another.
you can think about it as an evolution of using hand coded stubs, without needing dependency injection techniques.
the suck typing feature allows you to only override what you care about, or to have a class that overrides methods for many different classes at the same time, in one place.
@Roy
Get you now, yeah that makes sense. Still think it seems tricksy enough that it would throw most people. Guess I'd like the option to be explicit:
Isolate.Swap.CallTo(x => x.Talk).On(dog).WithCallTo(duck);
You could come back and say thats being too explicit and could result in fragile overspecified tests, and I agree...but I would have thought the choice would be useful.
@Colin
This is a good idea - we are actually planning to enable doing this through the WhenCalled() entry point:
Isolate.WhenCalled(() => x.Talk()).Do(() => y.Walk()); // or something along these lines.
This in addition to the entire object duck type swapping Roy showed above - it's a cool tool for the situations in which you would like to substitute an entire object.
We call the feature Duck-typing, but Suck-typing sounds like something we could get on the product backlog for an upcoming release :)