Best Practices, Mock Usage Pattern
There are a few ways that mocks can be used. As many of you who read my blog might guess I am not an OO Purist. I think that I am more of a Pragmatic OO. The same goes with unit tests, I don’t strongly believe that there must be one Assert per test, and I see many tests that verify the interaction and state in the same test.
But here are a few things to remember:
- You should Verify the Mocks between tests
This will allow the tests to fail if an expectation was not met - If your test fails (an exception thrown) you still need to clear your expectations
Otherwise you will leave fake behavior for the next test
Here is a pattern that will solve these issues.
/// <summary> /// This is the best practice tests with TypeMocks /// </summary> [TestFixture] public class MyTests { /// <summary> /// Clear mocks /// </summary> [TearDown] public void CleanUp() { MockManager.ClearAll(); } /// <summary> /// We will test with mocking /// </summary> [Test] public void TestWithMock() { // setup mock // run test // optional assert Assert.AreEqual(); // Verify mocks MockManager.Verify(); } }
2 Comments to “Best Practices, Mock Usage Pattern”
Recent Posts
- Product Status Peek – 2011
- Thanks Roy
- Typemock starts 2011 in a new location
- Agile Demos Smells
- I want loud disputes in our meetings
Categories
- .NET Tests
- Agile
- Code Integrity
- Community
- Debugging
- Fun
- Management for Geeks
- Marketing
- Product
- Release
- Reviews
- SharePoint
- TDD
- Time Management
- Uncategorized
- Unit Tests
Archives
- January 2011
- December 2010
- October 2010
- August 2010
- 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

Is there any particular reason that you are calling Verify() in the test? I have defaulted (perhaps wrongly) to putting all of my mock management calls into the SetUp and TearDown methods. If a test is run that does not use mocking then I am out a small bit of performance, but it is handy. It also allows me to refactor my tests more easily. Below is what I try to start with when testing a class with mocks.
[TestFixture]
public class MyTests {
#region Setup/tear down
[TestFixtureSetUp]
public void InitTestFixture() {
}
[TestFixtureTearDown]
public void CleanUpTestFixture() {
}
[SetUp]
public void InitTest() {
MockManager.Init();
}
[TearDown]
public void CleanUpTest() {
MockManager.Verify();
MockManager.ClearAll();
}
#endregion
}
Ian,
There are a few reasons to put Verify in the test method:
1. In those cases where the test throws some kind of exception. The TearDown will run a Verify and you will see many failures that will make it harder to find the real problem.
2. Since NUnit 2.2, all failures in the TearDown are ugly, with big call stacks making it harder to understand.
Note: There is no reason to call ClearAll right after Verify, because Verify clears all the mocks too. The reason that ClearAll is called in the TearDown are for those cases where the tests throws an exception.