While working on this project, I found a need to abstract away a base type that the unit tests use (in this instance, it was a queue type). I was only testing a single type (PriorityQueue); however, I wanted to create a new type, but all the basic tests for the new type are the same as the existing ones. This led me to investigate the TestCaseSource attribute in NUnit.
As a result, I needed a way to re-use the tests. There are definitely multiple ways to do this; the simplest one is probably to create a factory class, and pass in a string parameter. The only thing that put me off this is that you end up with the following test case:
[TestCase("test", "test9", "test", "test2", "test3", "test4", "test5", "test6", "test7", "test8", "test9"]
[TestCase("a1", "a", "a1", "b", "c", "d", "a"]
public void Queue\_Dequeue\_CheckResultOrdering(
string first, string last, params string[] queueItems)
{
Becoming:
[TestCase("PriorityQueue", "test", "test9", "test", "test2", "test3", "test4", "test5", "test6", "test7", "test8", "test9"]
[TestCase("PriorityQueue2", "test", "test9", "test", "test2", "test3", "test4", "test5", "test6", "test7", "test8", "test9"]
[TestCase("PriorityQueue", "a1", "a", "a1", "b", "c", "d", "a"]
[TestCase("PriorityQueue2", "a1", "a", "a1", "b", "c", "d", "a"]
public void Queue\_Dequeue\_CheckResultOrdering(
string queueType, string first, string last, params string[] queueItems)
{
This isn’t very scaleable when adding a third or fourth type.
TestCaseSource
It turns out that the (or an least an) answer to this is to use NUnit’s TestCaseSource attribute. The NUnit code base dog foods quite extensively, so that is not a bad place to look for examples of how this works; however, what I couldn’t find was a way to mix and match. To better illustrate the point; here’s the first test that I changed to use TestCaseSource:
[Test]
public void Queue\_NoEntries\_CheckCount()
{
// Arrange
PQueue.PriorityQueue<string> queue = new PQueue.PriorityQueue<string>();
// Act
int count = queue.Count();
// Assert
Assert.AreEqual(0, count);
}
Which became:
[Test, TestCaseSource(typeof(TestableQueueItemFactory), "ReturnQueueTypes")]
public void Queue\_NoEntries\_CheckCount(IQueue<string> queue)
{
// Arrange
// Act
int count = queue.Count();
// Assert
Assert.AreEqual(0, count);
}
(For completeness, the TestableQueueItemFactory is here):
public static class TestableQueueItemFactory
{
public static IEnumerable<IQueue<string>> ReturnQueueTypes()
{
yield return new PQueue.PriorityQueue<string>();
}
}
However, when you have a TestCase like the one above, there’s a need for the equivalent of this (which doesn’t work):
[Test, TestCaseSource(typeof(TestableQueueItemFactory), "ReturnQueueTypes")]
[TestCase("test", "test9", "test", "test2", "test3", "test4", "test5", "test6", "test7", "test8", "test9")]
[TestCase("a1", "a", "a1", "b", "c", "d", "a")]
public void Queue\_Dequeue\_CheckResultOrdering(string first, string last, params string[] queueItems)
{
A quick look at the NUnit code base reveals these attributes to be mutually exclusive.
Compromise
By no means is this a perfect solution, but the one that I settled on was to create a second TestCaseSource helper method, which looks like this (along with the test):
private static IEnumerable Queue\_Dequeue\_CheckResultOrdering\_TestCase()
{
foreach(var queueType in TestableQueueItemFactory.ReturnQueueTypes())
{
yield return new object[] { queueType, "test", "test9", new string[] { "test", "test2", "test3", "test4", "test5", "test6", "test7", "test8", "test9" } };
yield return new object[] { queueType, "a1", "a", new string[] { "a1", "b", "c", "d", "a" } };
}
}
[Test, TestCaseSource("Queue\_Dequeue\_CheckResultOrdering\_TestCase")]
public void Queue\_Dequeue\_CheckResultOrdering(
IQueue <string> queue, string first, string last, params string[] queueItems)
{
As you can see, the second helper method doesn’t really help readability, so it’s certainly not a perfect solution; in fact, with a single queue type, this makes the code more complex and less readable. However, When a second and third queue type are introduced, the test suddenly becomes resilient.
YAGNI
At first glance, this may appear to be an example of YAGNI. However, in this article, Martin Fowler does state:
Yagni only applies to capabilities built into the software to support a presumptive feature, it does not apply to effort to make the software easier to modify.
Which, I believe, is what we are doing here.
References
http://www.smaclellan.com/posts/parameterized-tests-made-simple/
https://github.com/nunit/docs/wiki/TestCaseSource-Attribute
http://dotnetgeek.tumblr.com/post/2851360238/exploiting-nunit-attributes-valuesourceattribute