[C#] Getting started with unit testing on VS 2017
This is my second article in my Getting started with C# series (no wait, I am just hyping things up hahaha). So the previous article was on installing VS2017, this one will be on an introduction to unit testing (UT) and the next one will be on debugging (don't start to hold your breath just yet).
OK why UT and not on programming for-loops etc. Well for starters, I need to address an immediate priority in my teaching duties but more importantly, UT seems to be a topic that is covered way back in many tutorials so much so that it could be the cause of that quite a few developers (me me sometimes) take a laid back attitude to UT their code. I can understand the pain here. UT is tedious (read boring till tears) and takes up a substantial amount of time which could be used for the core developmental activities (example drink coffee). Anyway, I am not here to discuss about the whys of UT but on how to do it or specifically getting started on it.
First, start a console application project and write some code.
Using System;
namespace ConsoleApp1
{
class Program
{
static void Main(string[] args)
{
Console.Write("Enter a number: ");
try
{
int n = int.Parse(Console.ReadLine());
if (IsZero(n))
{
Console.WriteLine("Zero!");
}
else
{
Console.WriteLine("It is {0}.", IsEven(n) ? "even" : "odd");
Console.WriteLine("It is {0}.", IsPositive(n) ? "positive" : "negative");
}
}
catch (FormatException e)
{
Console.WriteLine("Input is not a number");
}
}
static bool IsEven(int n)
{
return n % 2 == 0;
}
static bool IsOdd(int n)
{
return !IsEven(n);
}
static bool IsZero(int n)
{
return n == 0;
}
static bool IsPositive(int n)
{
return n > 0;
}
static bool IsNegative(int n)
{
return n < 0;
}
}
}
Now there is a really simple way to create unit tests. Simply right-click on the code and select "Create Unit Tests".
Unfortunately we encountered an issue right away.
Luckily, we can resolve this by simply applying the public access modified to the class and functions. It could be basically explained that the UT as a separate entity/project requiring access to the code.
The next step is to select all the functions then right-click and select "Create Unit Tests" again. This time, we will be presented with the following screen:
Click OK and the UT Framework will help create basic UTs for the functions that you had selected.
You can right-click and select "Run Tests" and you will encounter the following outcomes.
Well, it's kinda of like "guilty until proven otherwise" and it is the core principle of Test-Driven Development. Anyway, we have to start writing the UTs properly.
The basic idea of testing a function if it is working properly and as expected is to execute the function with an input and compare its output (aka actual) with the expected answer. For example, the IsEven function is expected to output true when its input is an even number and false otherwise. So if we input a 8 to the IsEven function, it is supposed to output a true and likewise for an input of 5, the output should be false.
This comparison is technically termed as an Assertion. Suppose we write the assertion in the following way:
[TestMethod()]
public void IsEvenTest()
{
int n = 8;
bool expected = true;
bool actual = Program.IsEven(8);
Assert.AreEqual(expected, actual);
}
Here, we will provide an expected value and assign the function output to the actual variable. Then we perform an assertion using the Assert.AreEqual method.
Right-click and select "Run Tests" and you should get the following now.
The next step will be to go back to the IsEvenTest and to repeat for multiple values (all the possible permutations if possible) and also for testing for values for which the function will return false. As you will find out, this is very tedious and most certainly require tenacity and often teeth -gashing.
[TestMethod()]
public void IsEvenTest()
{
int n = 8;
bool expected = true;
bool actual = Program.IsEven(n);
Assert.AreEqual(expected, actual);
n = 232342;
expected = true;
actual = Program.IsEven(n);
Assert.AreEqual(expected, actual);
n = 23;
expected = false;
actual = Program.IsEven(n);
Assert.AreEqual(expected, actual);
}
The common practice is to have separate test cases to test the various possible inputs and this means that usually we can have few hundreds or even thousands of test cases.
OK I so done with this article now. Hope it is of some help to you as it is for me. Remember that UT is the best answer to the question "Have you tested your code?". Have fun with UT!
it's so much easier in VS2017 as compared to VS2012