Mocks Aren't Stubs

The term 'Mock Objects' has become a popular one to describe special case objects that mimic real objects for testing. Most language environments now have frameworks that make it easy to create mock objects. What's often not realized, however, is that mock objects are but one form of special case test object, one that enables a different style of testing. In this article I'll explain how mock objects work, how they encourage testing based on behavior verification, and how the community around them uses them to develop a different style of testing. I first came across the term "mock object" a few years ago in the Extreme Programming (XP) community. But as often as not I see mock objects described poorly. This difference is actually two separate differences. Regular Tests I'll begin by illustrating the two styles with a simple example. These two behaviors imply a couple of tests, these look like pretty conventional JUnit tests. Tests with Mock Objects Using EasyMock class OrderStateTester...

Rhino Mocks Examples, with a fix | Girl Writes Code Jon Kruger created an excellent explanation of Rhino Mocks, using unit tests to demonstrate and illuminate the syntax and capabilities. (Found via @gar3t .) It needs one small correction, which I’d like to write about here so that I can link to and support Jon’s work, and because it gives the opportunity to clarify a subtle distinction between mocks and stubs and verified expectations. First, go check out Jon’s code , then come back here. The problem lies in the following test. [ Test ] public void Another_way_to_verify_expectations_instead_of_AssertWasCalled() var stub = MockRepository .GenerateStub< ISampleClass >(); // Here I'm setting up an expectation that a method will be called stub.Expect(s => s.MethodThatReturnsInteger( "foo" )).Return(5); //Sneaky Sharon comments out the "Act" part of the test: //var output = stub.MethodThatReturnsInteger("foo"); //Assert.AreEqual(5, output); // ... and now I'm verifying that the method was called stub.VerifyAllExpectations(); public class MyRealClass

Mocking Property Getters and Setters In typical unit testing scenarios , mocking property getters and setters isn't high on the list of areas of concern. Where it usually comes into play is when an entity’s properties’ values (or the act of setting them) are part of the scaffolding, or behavior for the system under test. An example is a scenario where entities are publishers of events and the system under test is the subscriber. Listing 1 – INotifyPropertyChanged Interface The premise of the pattern is that any time a property changes on the model, the PropertyChanged event gets raised, notifying any subscribers of the change. By implementing this interface on the models in your application (in addition to the benefits that you get from the XAML databinding engine), you can build an “IsDirty” flag that gets set if any property on your model changes. For our example, we are going to create an IEntity interface as well as a EntityBase class that implements the IEntity interface. Mocking Property Getters Summary Happy Coding!

Setting PropertyBehavior On All Properties With Rhino Mocks Although I am a big fan of Rhino Mocks , I typically favor State-Based over Interaction-Based unit testing , though I am not totally against Interaction Based testing. I often use Rhino Mocks to dynamically create Dummy objects and Fake objects rather than true Mocks, based on this definition given by Martin Fowler . Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists. Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example). Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test. Fortunately Rhino Mocks is well suited to this purpose. Here we have a very simple interface. public interface IAnimal { int Legs { get; set; } } Next, we have a simple class we want to test that interacts with IAnimal instances. Fair enough.

C# Corner: Inside Mocking Frameworks C# Corner Use Mocking Frameworks to Improve Code Quality In today's agile/TDD world, mocking has become an important tool in the development of a good, testable design. It's important to understand your mocking framework to make sure you can maximize its benefit. But before I talk about mocking frameworks, I want to review a little bit about subclassing in .NET. Even if you're familiar with subclassing, inheritance and polymorphism, I encourage you to read on. As I'm sure many of you know, to override a method is to create a subclass of an object and change the behavior of a method. public class SimpleInterestCalculator { public double Principal { get; set; } public double InterestRate { get; set; } public double Time { get; set; } public virtual double CalculateInterestAmount() { return Principal*InterestRate*Time; } } Note that we've made CalculateInterestAmount() virtual. Of course, you don't always have to change the behavior. And here's how we can use this to test the "Bank" class: