Question

I am currently working on a C# project. I have just started needing to learn how to do unit tests and am finding them pretty difficult to get my head around some parts of it. I have a function which returns a List array and I need to test this method is working correctly.

When I right click on the method in VS2010 and say create Unit Test it creates me the following code:

    [TestMethod()]
    public void readStreamTest()
    {
        ReadStream target = new ReadStream(); // TODO: Initialize to an appropriate value
        Stream stream = new MemoryStream(); // TODO: Initialize to an appropriate value
        StreamWriter sw = new StreamWriter(stream);

        string line = "My Line 1\n¬My Line 2\nMy Line 3\nMy Line 4\nMy Line 5\nMy Line 6\nMy Line 7";
        int numLines = 5; // TODO: Initialize to an appropriate value
        List<FileLine> lines = new List<FileLine>();
        int i = 0;
        while ( i != 7 )
        {
            lines.Add(new FileLine()
            {
                lineNo = i,
                lineContent = line
            });
            i++;
        }
        List<FileLine> expected = lines; // TODO: Initialize to an appropriate value
        List<FileLine> actual;
        actual = target.readStream(stream, numLines);
        //Assert.AreEqual(expected, actual);
        Assert.IsNotNull(expected);
    }

Some of it, like the initialisation of the list and adding items to the list using the array is what I have added myself to try and figure out what to do.

If anyone can provide any help on how I could test this, I don’t see how it can work with a list array.

Answer 1

Let’s solve your problem first, and then we can talk general testing pointers.

Assert.AreEqual is going to compare for reference equality, which is not what you want. What you really want is to compare that the contents are the same (I assume). This can be done using the Enumerable.SequenceEqual method like so:

Assert.IsTrue(expected.SequenceEqual(actual));

---

Now we can talk more generally about testing. I have posted about this before, but I’ll try to summarize the theme here.

Focus on Behavior!

Unit testing should be about behavior, not implementation details! This is the first and most basic principle in my opinion. It will inform every other decision you make.

Why is this such a big deal?

Because if you don’t do this, then your tests will be brittle. Changing the implementation details will break the tests, and that shouldn’t happen. Your unit tests should free you up to be able to refactor and improve the code with confidence. If your tests are tied to the implementation details this can’t happen, and you will always be fighting against your tests.

So what does this look like? Well lets compare two hypothetical tests:

[TestMethod]
public void TestThatUserInfoIsValidatedAndSaved()
{
    var user = new User{Name = "Bob"};
    UserService.SaveUser(user);

    //Check that data access got called to see if Bob exists
    //Check that validation got called
    //Check that data access got called to save bob
}

[TestMethod]
public void ShouldSaveNewUser()
{
    var user = new User{Name = "Bob"};
    UserService.SaveUser(user);

    //Check that bob was saved
}

In the preceding two methods, one is very granular in testing specific details about the method, while the other simply tests the intended behavior. If we change how that method works under the hood, then the first will break. However, the second test should continue to work just fine.

Your tests should describe “What” the system does, not “how” it does it.

Do this and you will have a much better experience with unit testing in the long run.