Almost all methods depend on one or more input parameters. To verify each and every one of these parameters, for boundary conditions, nulls and such generic cases, becomes an overload, for each method in a class. It also leads to writing repetitive test cases to check the same type of an input parameter. For example, consider the following method
public int FirstCheck(int first, int second)
{
return first + second;
}
To check both the integer variables for boundary conditions, negative values etc. using NUnit would require writing repeated test cases for each one of these variables. Similarly with strings, Dates and other value types. For reference types, a test for nulls is required. Writing test cases becomes a tedious task, and therefore a developer, may miss these cases. To solve this problem, I have tried to create an attribute to add to the existing ones in NUnit, which can be placed over a class. The NUnit core identifies this attribute, and redirects it to a custom test case builder which is added to create and run test cases for boundary values for value types, and nulls for reference types. An input to this attribute is an exception type, which is the expected exception when the test fails. Lets consider an example,
[TestParams(typeof(InvalidOperationException))]
public class TestParamsTester
{
public int FirstCheck(int first, int second)
{
return first + second;
}
public string SecondCheck(int first,int second)
{
return first.ToString() + second.ToString() ;
}
}
The attribute placed over the class implies that NUnit should test each and every parameter for all methods in this class. Also, when a test fails, NUnit expects an InvalidOperationException. When the class is loaded using NUnit (for better understanding, the NUnit-GUI is used here), the methods are added as test cases
When the test cases are run, we get the following results
With such a functionality provided by NUnit itself, a user does not need to use any new software to do such an automatic verification (just changing 2 dll's would enable NUnit to support this functionality). I am currently extending this verification process to have a user specify custom boundaries and cases using an XML file. Also, instead of creating one test case per method, all boundaries have a separate test case, for the end-user to immediately identify the failing verification.
What do you think of this idea?