Question

This is my first attempt to do unit tests, so please be patient with me.
I’m still trying to unit test a library that converts lists of POCOs to ADO.Recordsets.

Right now, I’m trying to write a test that creates a List<Poco>, converts it into a Recordset (using the method I want to test) and then checks if they contain the same information (like, if Poco.Foo == RS.Foo, and so on…).

This is the POCO:

public class TestPoco
{
    public string StringValue { get; set; }
    public int Int32Value { get; set; }
    public bool BoolValue { get; set; }
}

…and this is the test so far (I’m using xUnit.net):

[Fact]
public void TheTest()
{
    var input = new List<TestPoco>();
    input.Add(new TestPoco { BoolValue = true, Int32Value = 1, StringValue = "foo" });

    var actual = input.ToRecordset();

    Assert.Equal(actual.BoolValue, true);
    Assert.Equal(actual.Int32Value, 1);
    Assert.Equal(actual.StringValue, "foo");
}

What I don’t like about this are the three asserts at the end, one per property of the POCO.
I’ve read lots of times that multiple asserts in one test are evil (and I understand the reasons why, and I agree).

The problem is, how can I get rid of them?

I have Roy Osherove’s excellent book “The Art of Unit Testing” right in front of me, and he has an example which covers exactly this (for those who have the book: chapter 7.2.6, page 202/203):

In his example, the method under test returns an AnalyzedOutput object with several properties, and he wants to assert all the properties to check if each one contains the expected value.

The solution in this case:
Create another AnalyzedOutput instance, fill it with the expected values and assert if it’s equal to the one returned by the method under test (and override Equals() to be able to do this).

But I think I can’t do this in my case, because the method that I want to test returns an ADODB.Recordset.

And in order to create another Recordset with the expected values, I would first need to create it completely from scratch:

// this probably doesn't actually compile, the actual conversion method 
// doesn't exist yet and this is just to show the idea

var expected = new ADODB.RecordsetClass();
expected.Fields.Append("BoolValue", ADODB.DataTypeEnum.adBoolean);
expected.Fields.Append("Int32Value", ADODB.DataTypeEnum.adInteger);
expected.Fields.Append("StringValue", ADODB.DataTypeEnum.adVarWChar);

expected.AddNew();
expected.BoolValue = true;
expected.Int32Value = 1;
expected.StringValue = "foo";
expected.Update();

I don’t like this either, because this is basically a duplication of some of the code in the actual conversion method (the method under test), which is another thing to avoid in tests.

So…what can I do now?
Is this level of duplication still acceptable in this special situation, or is there a better way how to test this?

Answer 1

I’d argue that in the spirit of the thing, this is fine. The reason that multiple asserts are “evil”, if I recall correctly, is that it implies that you are testing multiple things in one test. In this case, you are indeed doing that in that you are testing each field, presumably to make sure this works for several different types. Since that’s all an object equality test would do anyway, I think you are in the clear.

If you really wanted to be militant about it, write one test per property (j/k!)