UNIT TESTING:
As soon as we think of testing , as a developer the first thing comes to mind is the Developer level Unit Testing. Now lets see some definitions and examples of the Developer level Testing.
UNIT TEST – THE CLASSIC DEFINITION :
A unit test is a piece of a code (usually a method) that invokes another piece of code and checks the correctness of some assumptions afterward. If the assumptions turn out to be wrong, the unit test has failed. A “unit” is a method or function.
Black box testing is different from white box testing. The kind of testing that you can perform on the code determines, among other things, the complexity of the unit test.
A black box test (also known as a "functional test") is one in which you feed it inputs and verify the outputs without being able to inspect the internal workings. Furthermore, one doesn't usually have information regarding:
- how the box handles errors
- whether your inputs are executing all code pathways
- how to modify your inputs so that all code pathways are executed
- dependencies on other resources
Black box testing limits your ability to thoroughly test the code, primarily because the you don't know if you're testing all the code pathways. Typically, a black box test only verifies that good inputs result in good outputs (hence the term "functional test").
Classes are often implemented as black boxes, giving the "user" of the class access only to the public methods and properties that the implementer selected.
A white box provides the information necessary to test all the possible pathways. This includes not only correct inputs, but incorrect inputs, so that error handlers can be verified as well. This provides several advantages:
- you know how the box handles errors
- you can usually write tests that verify all code pathways
- the unit test, being more complete, is a kind of documentation guideline that the implementer can use when actually writing the code in the box
- resource dependencies are known
- internal workings can be inspected
In the "write the test first" scenario, the ability to write complete tests is vital information to the person that ultimately implements the code, therefore a good white box unit test must ensure that, at least conceptually, all the different pathways are exercised.
Another benefit of white box testing is the ability for the unit test to inspect the internal state of the box after the test has been run. This can be useful to ensure that internal information is in the correct state, regardless of whether the output was correct. Even though classes are often implemented with many private methods and accessors. with C# and reflection, unit tests can be written which provide you the ability to invoke private methods and set/inspect private properties.
1.5 A simple unit test example
Assume we have a SimpleParser class in our project that we’d like to test as shown in listing 1.1. It takes in a string of 0 or more numbers with a comma between them. If there are no numbers it returns zero. For a single number it returns that number as an int. For multiple numbers it sums them all up and returns the sum (right now it can only handle zero or one number though):
Listing 1.1: A simple parser class we’d like to test
public class SimpleParser
{
public int ParseAndSum(string numbers)
{
if(numbers.Length==0)
{
return 0;
}
if(!numbers.Contains(","))
{
return int.Parse(numbers);
}
else
{
throw new InvalidOperationException("I can only handle 0 or 1 numbers for
now!");
}
}
}
We can add a simple console application project that has a reference to the assembly containing this class, and
write a method like this in a class called SimpleParserTests, as shown in listing 1.2.
The test is simply a method, which invokes the production class (production: the actual product you’re building
and would like to test) and then checks the returned value. If it’s not what is expected to be, it writes to the
console. It also catches any exception and writes it to the console.
Listing 1.2:A simple coded method that tests our SimpleParser class.
class SimpleParserTests
{
public static void TestReturnsZeroWhenEmptyString()
{
try
{
SimpleParser p = new SimpleParser();
int result = p.ParseAndSum(string.Empty);
if(result!=0)
{
Console.WriteLine(@"***
SimpleParserTests.TestReturnsZeroWhenEmptyString:
-------
Parse and sum should have returned 0 on an empty string");
}
}
catch (Exception e)
{
Console.WriteLine(e);
}
}
}
Next, we can simply invoke the tests we’ve written using a simple Main method run inside a console
application in this project, as seen in listing 1.3. The main method is used here as a simple test runner, which
invokes the tests one by one, letting them write out to the console for any problem. Since it’s an executable, this
can be run without human intervention (assuming no test pops up any interactive user dialogs).
Listing 1.3: Running our coded tests via a simple console application
public static void Main(string[] args)
{
try
{
SimpleParserTests.TestReturnsZeroWhenEmptyString();
}
catch (Exception e)
{
Console.WriteLine(e);
}
}
The test also catches any exception that might occur and writes it to the console output.
INTEGRATION TESTING:
Testing two or more dependent software modules as a group.
An integration test would exercise many units of code that work together to evaluate one or more results, while a unit test would usually exercise and test only a single unit in isolation.
NUnit is an application designed to facilitate unit testing. It consists of both a command line and Window's interface, allowing it to be used both interactively and in automated test batches or integrated with the build process. The following sections discuss NUnit as it applies to C# programming.
NUnit utilizes attributes to designate the different aspects of a unit test class.
The TestFixture attribute designates that a class is a test fixture. Classes thus designated contain setup, teardown, and unit tests.
The SetUp attribute is associated with a specific method inside the test fixture class. It instructs the unit test engine that this method should be called prior to invoking each unit test. A test fixture can only have one SetUp method.
The TearDown attribute is associated with a specific method inside the test fixture class. It instructs the unit test engine that this method should be called after invoking each unit test. A test fixture can only have one TearDownmethod.
The Test attribute indicates that a method in the test fixture is a unit test. The unit test engine invokes all the methods indicated with this attribute once per test fixture, invoking the set up method prior to the test method and the tear down method after the test method, if they have been defined.
The test method signature must be specific: public void xxx(), where "xxx" is a descriptive name of the test. In other words, a public method taking no parameters and returning no parameters.
Upon return from the method being tested, the unit test typically performs an assertion to ensure that the method worked correctly.
The ExpectedException attribute is an optional attribute that can be added to a unit test method (designated using the Test attribute). As unit testing should in part verify that the method under test throws the appropriate exceptions, this attribute causes the unit test engine to catch the exception and pass the test if the correct exception is thrown.
Methods that instead return an error status need to be tested using the Assertion class provided with NUnit.
The Ignore attribute is an optional attribute that can be added to a unit test method. This attribute instructs the unit test engine to ignore the associated method. A requires string indicating the reason for ignoring the test must be provided.
The Suite attribute is being deprecated. The original intent was to specify test subsets.
[TestFixture]
public class ATestFixtureClass
{ private ClassBeingTested cbt;
[SetUp]
public void Initialize()
{ cbt=new ClassBeingTested();
}
[TearDown]
public void Terminate()
{ cbt.Dispose();
}
[Test]
public void DoATest()
{ cbt.LoadImage("fish.jpg"); }
[Test, Ignore("Test to be implemented")] public void IgnoreThisTest()
{ }
[Test, ExpectedException(typeof(ArithmeticException))]
public void ThrowAnException()
{ throw new ArithmeticException("an exception"); }
}
