Unit testing a generic method not caring about the generic type

Question

I have the following code

public class MyCollection<T>
{
    public void Add(T obj) { ... }
public int Count { get; }

}

and the following unit test to check whether Add increases the Count property by one:

[Fact]
public void Add_ShouldIncreaseCount()
{
    var collection = new MyCollection<int>();
    var oldCount = collection.Count;
collection.Add(default);

Assert.Equal(collection.Count, oldCount + 1);

}

However, I feel like the test is not "good" as in it only shows that Add works for MyCollection<int>.

Do I have to add tests for more value types and also reference types (e.g. string etc.) or is there a way (such as AutoFixture's fixture.Create<T>() to create arbitrary values) to create a "dummy" type?

Is there a way to indicate that I do not care about the actual generic type? What are the best practices in this case?

score 6 · Accepted Answer · answered Dec 21 '20 at 13:04

Testing the degree of freedom that a generic class affords you is like testing a function that can take any int. There's no reasonable way to test every possible input, and no construct that I know of to ensure that the same test would succeed no matter what T is.

Therefore, you should do what you do with a normal function of int: you test a few different int values (in particular, boundary cases to test for off-by-one errors and such). Here this means that you test the Add() with an int instantiation, with a string instantiationr and perhaps with some totally other type. For instance, if your language has function types you might use that to demonstrate that your container really just stores the function, as opposed e.g. to calling it. Other than that I don't see what else due diligence would require.

score 0 · Answer 2 · answered Dec 21 '20 at 13:11

I would test with object first, it's the highest level thing you can use. Also it's the responsibility of classes that inherit object to conform to object, so if MyType encounters issues, it's more likely an issue with the type than this code. I would add tests for the most common anticipated implementations if you really want peace of mind, it's not that expensive to do. A general side note, I personally prefer magic numbers in unit tests, because it could potentially mask issues to use count to get the initial value.

Unit testing a generic method not caring about the generic type

2 Answers2