Single testing of several different results with one method
I am using NUnit 2.5 and I want to test a method that takes multiple parameters.
Is it possible to try testing them using the same test method with several different test cases, or will it be more difficult to maintain (or just point out the exact error) in the end?
My general idea is to try something like
[TestCase("valid", Result="validasd",
Description = "Valid string test, expecting valid answer")]
[TestCase(null, ExpectedException = typeof(ArgumentNullException),
Description = "Calling with null, expecting exception")]
[TestCase("", ExpectedException = typeof(ArgumentException),
Description = "Calling with an empty string, expecting exception")]
public string TestSubString(string value)
{
return MethodUnderTest(value);
}
Is this also the recommended usage - no explicit assertion, just checking the return value? Or should I stick with the normal way, or assert the value inside the method?
a source to share
I have found the TestCase attribute to be useful when testing methods that basically take some simple values, calculate with them, and then return a result. In these cases, writing such tests requires significantly less overhead and duplication.
This approach does not work when the method requires complex object parameters, because the TestCase attribute can only accept primitive types as input parameters to navigate to the method.
You can also consider writing a more typical unit test if:
- other developers on your team are not familiar with this technique.
- method signature that can change or accommodate more parameters
- if for testing more than a few test cases or combinations of values
- you need tests to run in a specific order
- you want to run your tests using ReSharper for Visual Studio (it does not currently recognize the TestCase attribute)
a source to share
I think the jury is still out of this parametric testing - the solid-state TDDers will most likely say that it violates the one assert per test principle, and they are probably right. The most important thing about unit testing is that when a test fails, you can quickly determine what exactly failed, what inputs caused it to fail, and reproduce it by repeating the same test. While the first two might not be an issue with this kind of testing framework, the third probably will (albeit with a smart enough tool you could get around it with).
Personally, I would say that at a minimum, you should split test cases into result sets, i.e. if two sets of parameters have the same expected result (e.g. ArgumentException), it is perfectly possible to combine them into the same test method.But in your example, all three parameters have different expected results, so you must put them on different test methods.
a source to share
For me, the best way is the one that forces you to write less code. The attribute is better in my opinion because:
- the test runner will group these methods under the same node tree
- visually, it is obvious that these 3 test cases are applied to the same code, only the method parameters are changed, and if the test fails, the error message will still tell you which parameters made it invalid.
- less code!
The downside is that the parameters and return value are hard-coded, so you cannot test dynamic or randomly generated parameters, which is useful in some cases.
a source to share
Wouldn't it be better to write something like this?
[Test]
public string TestSubString()
{
Assert.AreEqual("validasd", MethodUnderTest("valid"));
AssertEx.Throws<ArgumentNullException>(() => { MethodUnderTest(null); });
AssertEx.Throws<ArgumentException>(() => { MethodUnderTest(""); });
}
a source to share