我如何嘲笑这个？

Question

In a .NET windows app, I have a class named EmployeeManager. On instantiation, this class loads employees into a List from the database that haven't completed registration. I'd like to use EmployeeManager in unit test. However, I don't want to involve the database.

From what I understand about this scenario, I need an IEmployeeManager interface, which is only used for testing purposes. This doesn't seem right since the interface has no other use. However, it will allow me to create some EmployeeManager test class that loads employees without involving the database. This way, I can assign values that would have otherwise come from the database.

Is the above correct and do I need to Mock it? Mocking (Moq framework) seems to use lots of code just to do simple things such as assigning a property. I don't get the point. Why mock when I can just create a simple test class from IEmployeeManager that will provide what I need?

Answer 1

Inversion of control is your solution, not Mock objects. Here's why:

You mock the interface to make sure that some code that utilizes your IEmployeeManager is using it properly. You aren't using the test code to prove IEmployeeManager works. So there has to be another class that takes an IEmployeeManager, for instance, which you will actually be testing with your mock object.

If you are actually just testing EmployeeManager, you can do much better. Consider dependency injection. In this manner, you will expose a constructor for EmployeeManager that will take at least one parameter which is an interface. Your EmployeeManager code will internally use this interface for any implementation specific calls that it needs to make.

See Strategy Pattern

This will lead you into a whole, exciting world of Inversion of Control . And as you dig into that, you will find that problems like these have been effectively solved with IoC containers such as AutoFac , Ninject , and Structure Map , to name a few.

Mocking interfaces is great, and you can mock an interface that you then pass into IoC. But you'll find that IoC is a much more robust solution to your problem. And yes, while you might only be implementing a second alternative just for testing, it is still important to do for that very reason -- seperating the strategy under test from the business logic of EmployeeManager.

Answer 2

From what I understand about this scenario, I need an IEmployeeManager interface, which is only used for testing purposes. This doesn't seem right since the interface has no other use.

It's well worth creating the interface. Note also that the interface actually has multiple purposes:

1. The interface identifies roles or responsibilities provided by an actor. In this case, the interface identifies the roles and responsibilities of the EmployeeManager . By using an interface you're preventing an accidental dependency on something database specific.
2. The interface reduces coupling. Since your application won't depend on the EmployeeManager , you're free to swap out its implementation without needing to recompile the rest of the application. Of course, this depends on project structure, number of assemblies, etc., but it nevertheless allows this type of reuse.
3. The interface promotes testability. When you use an interface it becomes much easier to generate dynamic proxies that allow your software to be more easily tested.
4. The interface forces thought ¹ . Ok, I kind of already alluded to it, but it's worth saying again. Just using an interface alone should make you think about an object's roles and responsibilities. An interface shouldn't be a kitchen sink. An interface represents a cohesive set of roles and responsibilities. If an interface's methods aren't cohesive or aren't almost always used together then it's likely that an object has multiple roles. Though not necessarily bad, it implies that multiple distinct interfaces are better. The larger an interface the harder it is to make it covariant or contravariant and, therefore, more malleable in code.

However, it will allow me to create some EmployeeManager test class that loads employees without involving the database.... I don't get the point. Why mock when I can just create a simple test class from IEmployeeManager that will provide what I need?

As one poster pointed out, it sounds like you're talking about creating a stub test class. Mocking frameworks can be used to create stubs, but one of the most important features about them is that they allow you to test behavior instead of state. Now let's look at some examples. Assume the following:

interface IEmployeeManager {
    void AddEmployee(ProspectiveEmployee e);
    void RemoveEmployee(Employee e);
}

class HiringOfficer {
    private readonly IEmployeeManager manager
    public HiringOfficer(IEmployeeManager manager) {
        this.manager = manager;
    }
    public void HireProspect(ProspectiveEmployee e) {
        manager.AddEmployee(e);
    }
}

When we test the HiringOfficer 's HireEmployee behavior, we're interested in validating that he correctly communicated to the employee manager that this perspective employee be added as an employee. You'll often see something like this:

// you have an interface IEmployeeManager and a stub class
// called TestableEmployeeManager that implements IEmployeeManager
// that is pre-populated with test data
[Test]
public void HiringOfficerAddsProspectiveEmployeeToDatabase() {
    var manager = new TestableEmployeeManager(); // Arrange
    var officer = new HiringOfficer(manager); // BTW: poor example of real-world DI
    var prospect = CreateProspect();
    Assert.AreEqual(4, manager.EmployeeCount());

    officer.HireProspect(prospect); // Act

    Assert.AreEqual(5, manager.EmployeeCount()); // Assert
    Assert.AreEqual("John", manager.Employees[4].FirstName);
    Assert.AreEqual("Doe", manager.Employees[4].LastName);
    //...
}

The above test is reasonable... but not good. It's a state-based test. That is, it verifies the behavior by checking the state before and after some action. Sometimes this is the only way to test things; sometimes it's the best way to test something.

But , testing behavior is often better, and this is where mocking frameworks shine:

// using Moq for mocking
[Test]
public void HiringOfficerCommunicatesAdditionOfNewEmployee() {
    var mockEmployeeManager = new Mock<EmployeeManager>(); // Arrange
    var officer = new HiringOfficer(mockEmployeeManager.Object);
    var prospect = CreateProspect();

    officer.HireProspect(prospect); // Act

    mockEmployeeManager.Verify(m => m.AddEmployee(prospect), Times.Once); // Assert
}

In the above we tested the only thing that really mattered -- that the hiring officer communicated to the employee manager that a new employee needed to be added (once, and only once... though I actually wouldn't bother checking the count in this case). Not only that, I validated that the employee that I asked the hiring officer to hire was added by the employee manager. I've tested the critical behavior. I didn't need even a simple test stub. My test was shorter. The actual behavior was much more evident -- it becomes possible to see the interaction and validate interaction between objects.

It is possible to make your stub test class record interactions, but then you're emulating the mocking frameworks. If you're going to test behavior -- use a mocking framework.

As another poster mentioned, dependency injection (DI) and inversion of control (IoC) are important. My example above isn't a good example of this, but both should be carefully considered and judiciously used. There's a lot of writing on the subject available .

¹ - Yes, thinking is still optional, but I'd strongly recommend it;).

Answer 3

Extracting interface in your scenario is a good idea. I would not worry too much about the fact that you only need this for testing. Extracting this interface makes your code decoupled from database. After that you will have a choice between writing your own implementation for testing or use mocking framework to generate this implementation for you. This is a matter of personal preference. It depends on how familiar you are with mocking framework and whether you want to spend time learning new syntax.

In my opinion it is worth learning. It will save you a lot of typing. They are also flexible and don't always require an interface to generate test implementation. RhinoMocks for example can mock concrete classes as long they have empty constructor and methods are virtual. Another advantage is that mocking APIs use consistent naming so you will get familiar with 'Mocks', 'Stubs' etc. In your scenario by the way you need stub, not mock . Writing an actual mock manually may be more labor intensive than using framework.

The danger with mocking frameworks is that some of them are so powerful and can mock pretty much anything, including private fields ( TypeMock ). In other words they are too forgiving to design mistakes and allow you to write very coupled code.

This is a good read on the subject of hand written vs. generated stubs

Answer 4

Creating an IEmployeeManager interface in order to be able to mock is that way most .NET developers would go about making such a class testable.

Another option is to inherit from EmployeeManager and override the method you want to test so it will not involve the database - this too means you will need to change your design.

Answer 5

By making your classes implement Interfaces you are not only making them more testable, you're making your application more flexible and maintainable. When you say "This doesn't seem right since the interface has no other use", is flawed since it allows you to loosely couple your classes.

If I could suggest a couple of books Head First Design Patterns and Head First Software Development will do a much better job of explaining the concepts then I could in a SO answer.

If you don't want to use a mocking framework like Moq, it's simple enough to roll your own mock/stubs, here is a quick blog post on it Rolling your own Mock Objects