Abstract
In today's software application development process, testing plays a critical
role. Though there are various types of testing being done by the team, from the
developer's perspective Unit Testing is critical and Unit Tests allow the
developers to write bug-free code.
Microsoft Visual Studio and .NET has its own Unit Test framework that is
separate from NUnit and other Automation Testing Frameworks.
Defining System Under Test (SUT)
Let's say I have developed some business logic for my application that does some
mathematical calculation based on user input and is available via MathLibrary.dll. Hence, it is very critical to have the business logic well
tested on various parameters that the user might pass. So my business logic is
"System Under Test " from Unit Test perspective. The following is the source code of MathLibrary business logic component.
- using System;
- namespace MathLibrary
- {
- public class MathClass
- {
- public int Sum(int n1, int n2)
- {
- if (n1 <= 0 && n2 <= 0)
- {
- throw new ArgumentException("No Zero or Negative are allowed");
- }
- else
- {
- return n1 + n2;
- }
- }
- }
- }
Since, it's a DLL component, test coverage of this is very critical for ensuring
that the business logic is intact and returns the correct results.
To do so, instead of relying on a Manual Test Process using a UI that will be cumbersome and tedious to continuously test the sanity of the business
logic, we can choose to automate this test process.
As you might have noticed, we have written the Sum function (in MathLibrary.dll)
in a Test Driven style. In other words, the parameters passed are also being
validated for all the following possible test scenarios.
- If the argument is positive and non-zero, then the sum of the arguments passed is returned.
- If the argument passed is 0 ("zero"), then an exception is thrown.
- If the argument passed is negative, then an exception is thrown.
How to approach Test Automation in general
Irrespective of what Unit Test tool and development technology you use, the test process depends on the following two things.
- Expected: Before we really do a test, our test case tells us what to expect for verifying success. For example, in the case of a sum taking two integers, we expect it to return the exact result of adding two numbers.
- Actual: When you do the test what your result is.
If Expected meets the Actual, then your Test Case has passed, otherwise your test case has failed.
Hence we need to do Test Coverage for all the Test Cases in the test scenarios described previously.
To do so, we will use Microsoft Visual Studio 2008 or 2010 and then open a New Test Project as shown in the following screenshot.
After this project has loaded, it will have a file UnitTest1.cs in it, this is the file you will be automating; we have created all the Test Cases for the MathLibrary.dll (our business logic).
In order to Automate the Test Cases in Microsoft Visual Studio using the Unit Testing Framework, you need to understand a few more things.
- Test Automation Framework: Microsoft has its Unit Testing Framework implemented in a namespace that is Microsoft.VisualStudio.TestTools.UnitTesting.
- [TestMethod] attribute: This is the attribute that needs to be present on each method that will actually represent a TestCase.
- Assert class: This class is a part of Microsoft's Unit Testing framework and we can use this class to verify that our Actual and Expected are the same or not and so on.
As said above, for each and every Test Case we need to write Automation code.
Note: Before we start coding the Automated TestCases, don't forget to add all the References, WebReferences and so on, that your test infrastructure will use.
I have covered four Test Cases for the sum function in MathLibrary.dll.
// Test Case#1: to verify if passed ints are returning right result.
- [TestMethod]
- public void TestSumResultAreEqual()
- {
- MathLibrary.MathClass objMath = new MathClass();
- Assert < > .AreEqual(24, objMath.Sum(12, 12));
- }
// Test Case#2: to verify if passed ints are not returning right result.
- [TestMethod]
- public void TestSumResultAreNotEqual()
- {
- MathLibrary.MathClass objMath = new MathClass();
- Assert.AreNotEqual(25, objMath.Sum(12, 12));
- }
// Test Case#3: to verify if passed ints are actually Zero.
- [TestMethod]
- public void TestSumThrowExceptionWhenZero()
- {
- MathLibrary.MathClass objMath = new MathClass();
- try
- {
- objMath.Sum(0, 0);
- }
- catch (ArgumentException)
- {
-
- }
- }
// Test Case#4: to verify if passed ints are actually Negative.
- [TestMethod]
- public void TestSumThrowExceptionWhenNegative()
- {
- MathLibrary.MathClass objMath = new MathClass();
- try
- {
- objMath.Sum(-123, -456);
- }
- catch (ArgumentException)
- {
-
- }
- }
Once you have coded all the Test Cases to Test the functionality, it's time to build the code and a TestProjectName.dll will be produced.
Testing the automation code The following are the two ways to Test your automation code now:
Using the Visual Studio IDE Build and then run the project within Visual Studio. You will see all the TestMethods being executed and the Test Results are shown, as shown in the following screenshot.
Using Visual Studio's command prompt Open Visual Studio's command prompt and navigate to the folder where the TestProjectName.dll is located and then run this command.
mstest /testcontainer:TestProjectName.dll.
Summary
This article explained the approach to use Test Automation using Microsoft Visual Studio's Unit Testing Framework, some basic fundamentals about the framework, what is expected out of a test and how to automate a business logic in a DLL form. The same approach can be used to even automate a WebService component and so on.