Question

Possible Duplicate:
Hard-Coded Mock Objects vs Mocking Framework

I think I’m finally beginning to understand what unit tests are intended to solve, but am still having trouble implementing all of the details. I’ve come to the conclusion that I may require a “mock” (and I use this term lightly since I’m not sure I need an entire framework like Moq) object to get the job done.

As an example of the issue I have been running in to, consider an implementation of the Repository Pattern (or similar). As I currently understand, I would need (at a minimum) tests for each of the Add(), Get(), and Remove() class methods. This is fine, except suppose I want to test how the Add() method handles null references. In this case, would I merely define a simple class within the test project and set an instance of this to null within the appropriate unit test?

Example Unit Test (Illustration):

[TestMethod]
public void TestAdd_Null()
{
    IRepository<MockObject> repository = (IRepository<MockObject>)(new Repository<MockObject>());
    MockObject testObject = null;

    repository.Add(testObject);

    Assert.IsNotNull(repository.Entity);
}

// I'm thinking I should implement something like this exclusively within the Test project.
// Is this reasonable? Or should I be looking into something else?
internal class MockObject
{
    public String Name { get; set; }
}

Answer 1

I’d go as far as to say that software testing, is like The Matrix. No one can be told what software testing is, you have to see it for yourself. Most non-believers haven’t given testing a fair chance and never tried doing some testing. Welcome to the club!

The tricky thing about testing though is that it’s quite hard to write tests, it’s also challenging sometimes to write testable code. There are however many great tools and techniques out there today that you should invest in to become a better software engineer.

Mocks provide dummies that you’d otherwise have to write yourself, mocks are convenient. Your repository in this case is not an actual persistence service in this case it simply provides a contract to test with. If adding a null reference isn’t supposed to be possible you should have a test cases which expect such an operation to fail. I believe this goes without saying but it’s important to test this to.

A library such as Moq could be very helpful here because a dummy repository does nothing and you actually want an assertion to take place here. I don’t see how a property Entity after something was added is needed here (other than to maybe make it easier to write the test). But I also think that it’s the wrong way to assert the expected behavior.

To some extent what you are doing is actually referred to as integration testing because you are not testing an isolated unit your using a mock factory to test the interaction between two components. These kinds of tests are very important but also hard to deal with if they weren’t designed to be testable. And this is why we have things such as dependency injection.

Your question doesn’t really require a specific answer, but you’re on the right track and I hope this will give you some insight and additional confidence when doing software testing.