Question

Consider the following class:

public class MyIntSet
{
    private List<int> _list = new List<int>();

    public void Add(int num)
    {
        if (!_list.Contains(num))
            _list.Add(num);
    }

    public bool Contains(int num)
    {
        return _list.Contains(num);
    }
}

Following the “only test one thing” principle, suppose I want to test the “Add” function.
Consider the following possibility for such a test:

[TestClass]
public class MyIntSetTests
{
    [TestMethod]
    public void Add_AddOneNumber_SetContainsAddedNumber()
    {
        MyIntSet set = new MyIntSet();
        int num = 0;

        set.Add(num);
        Assert.IsTrue(set.Contains(num));
    }
}

My problem with this solution is that it actually tests 2 methods: Add() and Contains().
Theoretically, there could be a bug in both, that only manifests in scenarios where they are not called one after the other. Of course, Contains() now servers as a thin wrapper for List’s Contains() which shouldn’t be tested in itself, but what if it changes to something more complex in the future? Perhaps a simple “thin wrap” method should always be kept for testing purposes ?

An alternative approach might suggest mocking out or exposing (possibly using InternalsVisibleTo or PrivateObject) the private _list member and have the test inspect it directly, but that could potentially create test maintainability problems if someday the internal list is replaced by some other collection (maybe C5).

Is there a better way to do this?
Are any of my arguments against the above implementations flawed?

Thanks in advance,
JC

Answer 1

Your test seems perfectly OK to me. You may have misunderstood a principle of unit testing.

A single test should (ideally) only test one thing, that is true, but that does not mean that it should test only one method; rather it should only test one behaviour (an invariant, adherence to a certain business rule, etc.) .

Your test tests the behaviour “if you add to a new set, it is no longer empty”, which is a single behaviour :-).

To address your other points:

• Theoretically, there could be a bug in both, that only manifests in scenarios where they are not called one after the other.
  True, but that just means you need more tests :-). For example, add two numbers, then call Contains, or call Contains without Add.

• An alternative approach might suggest mocking out or exposing (possibly using InternalsVisibleTo) the private _list member and have the test inspect it directly, but that could potentially create test maintainability problems[…]
  Very true, so don’t do this. A unit test should always be against the public interface of the unit under test. That’s why it’s called a unit test, and not a “messing around inside a unit”-test ;-).