Ruby Style Mocking in .NET
I had a great discussion with a college about the difficulties of understanding the technical parts of the automated Mocking frameworks.
The one point that takes some time to grasp is the fact that methods are written within the test that are not actually called, but are stubs/mocks that will be called at a later time. This is true to all frameworks. He then suggested that having the ability to swap one type with another would help in understanding the flow of the test. So I whipped together some code to do just that.
Using this code it is possible to swap one type with another. The two types must have the same methods, but the swapping type doesn’t need to have all the methods of the original type.
Here is an example:
public class OriginalClass { public int ReturnOne() { return 1; } public static int StaticReturnOne() { return 1; } }
Static Method Swapping
Suppose we want to fake the static methods of the OriginalClass, we simply write a new class.
public class FakeClass { public static int StaticReturnOne() { return 2; } }
Note: apart from the names of the methods the two classes are not related.
Here is how we fake the calls,
- We Swap the OriginalClass with the FakeClass by: Swap.StaticCalls()
- All static calls to OriginalClass methods that exist in the FakeClass are diverted to the FakeClass.
- We Unswap the types at the end of the test by Swap.Rollback()
[TestMethod] public void SwapStatic_CallsFake() { Swap.StaticCalls<OriginalClass, FakeClass>(); Assert.AreEqual(2, OriginalClass.StaticReturnOne()); Swap.Rollback(); }
Instance Swapping
We can do the same with instances, we can create a new FakeClass and swap the instances.
public class FakeClass { public int ReturnOne() { return 2; } }
Note: again, apart from the names of the methods the two classes are not related, but they both might implement the same interface or base class and thus support refactoring.
Here is how we fake the calls,
- We Swap the next new OriginalClass with the FakeClass by Swap.NextNew().
- All calls to that OriginalClass method which exist in the FakeClass are diverted to the FakeClass.
[TestMethod] public void SwapInstance_CallsFake() { Swap.NextNew<OriginalClass, FakeClass>(); OriginalClass swappedInstance = new OriginalClass(); Assert.AreEqual(2, swappedInstance.ReturnOne()); }
Missing Methods
At this stage the missing methods of the swapped type can have 2 behaviors:
- Call the original class (Default or UndefinedMethods.CallOriginal)
- Do nothing and Return a default value (UndefinedMethods.Ignore)
This is set in the swap statements.
Downloads
3 Comments to “Ruby Style Mocking in .NET”
Recent Posts
- Unacceptable: Unit testing will take 20 years to catch on
- The 4 reasons why we DIDN’T choose Oslo
- Typemock Academy Launch
- The First Rule to Software Craftsmanship
- Goal-driven Development
Categories
- .NET Tests
- Agile
- Code Integrity
- Community
- Debugging
- Fun
- Management for Geeks
- Marketing
- Product
- Release
- Reviews
- SharePoint
- TDD
- Time Management
- Uncategorized
- Unit Tests
Archives
- May 2010
- April 2010
- March 2010
- February 2010
- December 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- December 2008
- November 2008
- August 2008
- July 2008
- May 2008
- April 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006

[...] In other languages where objects can be swapped without Dependency Injection, there is no-one, calling these features – Bad Practice, just the opposite. They are called ‘Power features’, because that is what they are. [...]
[...] Eli Lopian, Typemock CEO and awesome Coder, just created a nice little API wrapper around Typemock Isolator that would allow a very simple and readable "Swapping" effect between classes. It would allow you to write code like this: [...]
[...] I have talked in the past about Ruby Style Isolating (Dynamically Typed), now it is part of the AAA syntax. [...]