Introduction

A test project contains unit tests. The unit tests contain test methods. How many test methods should a unit test contain and how should
they be named to still behave like a control over the whole testing process? This article shows, that with only one
TestMethod1() you can produce unit tests covering multiple test cases and you
won't lose the grip.

First I'll show you how to create test cases for simple scenarios - using only constant values. Further you'll see creating test cases for more complicated objects containing references to other objects or services.

Background

Instead of creating multiple test methods, e.g.,
TestDivisionIfDivisorIs0(), TestDivisionIfDivisorIs1(), TestDivisionIfDivisorIsBiggerThanDividend(), etc.,
you create TestCases defining the test environment and provide them to the test method one after another. The test method handles the test cases in a loop.

The TestCase class contains input parameters of the Divide() method, the expected result, and the exception type if any exception should be thrown
by the tested method. The additional property Description informs about the test conditions in a human readable way and helps us in identifying the test case.

TestMethod1() takes test cases from getTestCases() one after another and for each test case it initializes the test environment,
then the tested class is created, the tested method is invoked, and the expected result is compared with the computed one.

Providing new test cases is very easy by extending the getTestCases() method with new items.

In the above way we provide all test cases from a single place describing them in a human readable way which helps us
in finding a failed test case during debugging.

Advanced scenario - using Mocks

The above example is simple. There are only constant values provided to the test case. Imagine a method making computations based on current time. At first replacing DateTime.Now with ITimeProvider would be necessary to make tests available.

Summary

Some say (thanks for the feedback), this approach could be replaced using NUnit and its TestCaseAttribute. Indeed this could be done in the simple scenario - divide example - but the advanced one -using ITimeProvider mock - needs creating its objects in the runtime.

At a first glance this
approach could have much overhead, but you could see the advantages of this pattern ordering each TestUnit into TestCase, getTestCases() and a TestMethod1() instead
of creating multiple test methods with their helper methods and naming them spontaneously.

Thanks for reading, for your comments, and for rating my article.

Points of
interest

My main point of interest is the optimization of the C# source code. If you have any suggestions
for this article please make a comment below. If you like this article please rate it with 5. If you're interested in writing clean (not stinky) code I recommend you visiting my latest
Open Source project for creating modular .NET applications - mcmframework.codeplex.com.