Structure of Unit Test class

For the unit test to be recognized by the Team System testing tools, this source-code file must reside in a test project, which in turn is a part of a Visual Studio solution. When you build this project, or the entire solution, the test project is built into an assembly that contains the executable unit test.

All unit test methods are marked with the [TestMethod()] attribute, <TestMethod()> in Visual Basic, and are members of the [TestClass()] class. In turn, this class is defined in the namespaceMicrosoft.VisualStudio.TestTools.UnitTesting. When you generate a unit test, you see that this namespace is included at the beginning of the generated file, in a using or Imports statement.

Unit Test Attributes and Properties

In addition to the [TestMethod()] attribute of the unit test method and the [TestClass()] attribute of its containing class, other attributes are used to enable specific unit-test functionality. Primary among these attributes are[TestInitialize()] and [TestCleanup()]. Use a method marked with [TestInitialize()] to prepare aspects of the environment in which your unit test will run; the purpose of doing this is to establish a known state for running your unit test. For example, you may use a [TestInitialize()] method to copy, alter, or create certain data files that your test will use.

Use a method marked with [TestCleanup()] to return the environment to a known state after a test has run; this might mean deleting files in folders, or returning a database to a known state. An example of this is resetting an inventory database to an initial state after testing a method used in an order-entry application. Furthermore, it is recommended that you use cleanup code in a [TestCleanup()]or ClassCleanup method and not in a finalizer method. Exceptions that are thrown from a finalizer method will not be caught, and can cause unexpected results.

An important property on test classes is the TestContext property. This property contains information including the name of the unit test that is currently running, the deployment directory, the names of log files, and for data-driven testing, the database to which you are connected. The TestContext property returns a TestContext instance. For more information, see Using the TestContext Class.

Unit Test Example

The following code snippet shows a simple unit test written in C#.

[TestMethod()]
public void DebitTest()
{
    string customerName = "Mr. Bryan Walton"; 
    double balance = 11.99; 
    BankAccount target = new BankAccount(customerName, balance);
    double amount = 11.22; 
    target.Debit(amount);
    Assert.AreEqual((System.Convert.ToDouble(0.77)), target.Balance, 0.05); // 0.05 is tolerance for floating-point comparison
    //Assert.Inconclusive("A method that does not return a value cannot be verified.");
}

For another example, see Coding a Data-Driven Unit Test.

Unit Test Outcomes

There are three ways to verify that a unit test has passed:

• Use one or more Assert statements to validate specific outcomes. For more information, see Using Assert Statements.
• Verify that no exception was thrown. It is still advisable to use one or more Assert statements.
• Verify that a particular exception is thrown. You can do this by using the ExpectedExceptionAttribute attribute.

Using Assert Statements

If the Pass or Fail result that a test produces is more informative or important to you than the actions that the test might complete, you should use one or more Assert statements in the test's code.

The test engine assumes that every unit test starts in a passing state. The test remains in that state until an Assert statement produces a result that contradicts the passing state, changing it from Pass to Fail or Inconclusive, or until an exception not specified in an ExpectedExceptionAttribute attribute is thrown. In another words, a unit test without an Assert statement will produce a Pass result every time it is run. This is not necessarily a useless test; you might just want to exercise the code to make sure it runs without throwing an exception. Code exercised in a unit test will be reported as covered in the code-coverage statistics regardless of whether the test produced a decisive result or even contained an Assert statement.

However, to verify that a specific action is being taken or a specific state is being reached, you must use Asserts. Several Assert statements are available to you in the Microsoft.VisualStudio.TestTools.UnitTesting namespace. The various Assert statements give you flexibility; for example, you can force a test to fail by using the statement Assert.Fail(). In addition to these Assert statements, you can, of course, construct your own custom functionality, perhaps by using Assert statements in if blocks.

Regardless of what results a test returns, it passes or fails depending on its Assert statements. If a test contains several Asserts, the state of the test remains Pass until an Assert is encountered that changes the state to Fail or Inconclusive.

Mocking using MOQ framework

In this article we will understand various mocking setups using Moq framework. Basically those setups help during the of unit testing of an application. If you have experience in unit testing then you are probably aware of these concepts. We know that mocking is an operation where we mimic the original operation with our custom or fake operation. At the time of application development, we sometimes see that one component is dependent on another component and we cannot wait until the completion of the dependent object.

In this situation, the concept of mocking comes into the picture. The mock object will mimic the original object, so that we can carry on with the development process. There are many mocking frameworks on the market which we can use for our mock object creation. Moq is one of them. It is free and simple to use. In this article we will use Moq as our mocking framework. At the time of the mock setup there might be different situations which we need to implement during unit test configuration. In this example we will understand a few of the important setups of Moq framework.

At first, give the reference of Moq framework to your application. Once you give the reference, it will show in the reference folder of the solution, as shown below.

So, let’s start with the first configuration.

Returns statement to return value

We can setup the expected return value to a function. In this example we will setup the Hello() function using a mock object and then we will setup so that after the execution of the Hello() function it will always return "true." Here, true is a primitive type value. If we are in need we can return our custom complex type too. Please notice that we have declared the Hello() function as virtual, because Moq demands that. The function should defined as virtual when we are going to mock a concrete implementation. Have a look at the below code.

namespace TestMVC

{

    public class TestClass

    {

        public virtual Boolean Hello()

        {

            throw new Exception();

        }

    }

    [TestClass]

    public class MVCUnitTest

    {

        [TestMethod]

        public void MockAlways()

        {

            var mock = new Mock<TestClass>();

            mock.Setup(x => x.Hello()).Returns(true);

            Assert.AreEqual(mock.Object.Hello(), true);

        }

    }

}

Perform certain task after execution of certain function

This is another very important setup. Sometime it’s needed to perform certain operations after the completion of other operations or after the execution of some function. For example, we want to count the number of times of a function execution, and will assess those times in order to influence our decisions. In this situation we can setupcallback() in time of mock. Here is a sample example.

 [TestClass]

    public class MVCUnitTest

    {

        [TestMethod]

        public void MockAlways()

        {

            string status = "";

            var mock = new Mock<Service>();

            mock.Setup(x => x.CallService()).Returns(true).Callback(() => {

                //Do some other stuff

                status = "FunctionCalled";

            });

            var consumer = new ServiceConsumer(mock.Object);

            Assert.AreEqual(consumer.Execute(), true);

            if (status == "FunctionCalled")

            {

                //perform other task when finish the first

            }

        }

    }

Once it completes the execution of the CallService() function, it immediately will execute callback and perform some other operation. In this example just we are setting some variable value and it might check further to take decisions in other steps.

Return multiple values sequentially from mocked function

This is another important setup where the mocked function (I mean the function setup associated with mock object) will return different values per each call. Here is a simple implementation:

using System;

using ConsoleApp;

using Microsoft.VisualStudio.TestTools.UnitTesting;

using Moq;

using ConsoleApp;

using System.Collections.Generic;

namespace TestMVC

{

    public class TestClass

    {

        public virtual Boolean ReturnSequence()

        {

            throw new Exception();

        }

    }

    [TestClass]

    public class MVCUnitTest

    {

        [TestMethod]

        public void MockAlways()

        {

            var mock = new Mock<TestClass>();

           

            //First Return True then false

            mock.SetupSequence(x => x.ReturnSequence())

                .Returns(true)

                .Returns(false);

            Assert.AreEqual(mock.Object.ReturnSequence(), true);

            Assert.AreEqual(mock.Object.ReturnSequence(), false);

        }

    }

}

In this example we have used multiple Returns() statements. The first time it will return true and the next time it will return false. Here is the output and we are seeing that the test is getting passed, as we expected.

Throws exception in second time

There might be certain situations where we want a configuration when the mocked function will return a value the first time, but in if called a second time it will throw an exception. In this example the function will return true at the first time and in the second call it will throw an exception.

namespace TestMVC

{

    public class TestClass

    {

        public virtual Boolean Function()

        {

            throw new Exception();

        }

    }

    [TestClass]

    public class MVCUnitTest

    {

        [TestMethod]

        public void MockAlways()

        {

            var mock = new Mock<TestClass>();

           

            //First Return True then Throws exception

            mock.SetupSequence(x => x.Function())

                .Returns(true)

                .Throws(new Exception());

            Assert.AreEqual(mock.Object.Function(), true);

            Assert.AreEqual(mock.Object.Function(), true);

        }

    }

}

We are seeing that it is throwing exception in second call.

CallBase() to call original implementation

This setup is helpful when we want to call the original function rather than mocked function. In this example,Function() is not mocked, we are calling the original function with the help of CallBase(). As we throw an exception from Function() intentionally, the test should throw an exception.

namespace TestMVC

{

    public class TestClass

    {

        public virtual Boolean Function()

        {

            throw new Exception();

        }

    }

    [TestClass]

    public class MVCUnitTest

    {

        [TestMethod]

        public void MockAlways()

        {

            var mock = new Mock<TestClass>();

            mock.CallBase = true;

            mock.SetupSequence(x => x.Function()).CallBase();

               

            Assert.AreEqual(mock.Object.Function(), true);

        }

    }

}

And it’s throwing exception from Function().

Mock Generic class

The mocking mechanism of the generic class is just like normal class mocking. Have a look in the below example:

public class Hello

   {

   }

   public class TestClass <T> where T : class

   {

       public virtual Boolean Function()

       {

           throw new Exception();

       }

   }

   [TestClass]

   public class MVCUnitTest

   {

       [TestMethod]

       public void MockAlways()

       {

           var mock = new Mock<TestClass<Hello>>();

           mock.SetupSequence(x => x.Function()).Returns(true);

           Assert.AreEqual(mock.Object.Function(), true);

       }

   }

Border line

In this article we have learned a few important mock setups using the Moq framework. In my next article I am planning to explore mocking more in depth.

MOQ framework first program

There are several mocking frameworks to be used in testing environments such as NMock, RhinoMocks, FakeItEasy and Moq to isolate units to be tested from the underlying dependencies. Although Moq is a relatively new mocking framework, this framework has been adapted by the developers because it's very easy to use not following the traditional mock pattern Record/Replay which is very opaque and unintuitive, it supports full VS Intellisense when creating the mock objects as well as it supports the new features of Microsoft.NET 2.0/3.5/4.0 such as dynamic typing, lambda expressions and LINQ expressions in C#. So, you as a developer will have a very low learning curve when using mocking frameworks.

In this article, I will explain how to use this amazing mocking framework.

Let's suppose we need to build a Calculator which provides basic arithmetic operations and a currency conversion operation (in this case, converting a dollar to Chilean pesos according to the actual exchange rate).

Let's define the ICalculator interface (see Listing 1).

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

namespace CalculatorPkg

{

    public interface ICalculator

    {

        int Add(int param1, int param2);

        int Subtract(int param1, int param2);

        int Multipy(int param1, int param2);

        int Divide(int param1, int param2);

        int ConvertUSDtoCLP(int unit);

    }

}

Listing 1

Let's suppose that we're going to consume an external service which provides the actual exchange rate for the USD and CLP. Let's define the IUSD_CLP_ExchangeRateFeed interface (see Listing 2).

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

namespace MoneyExchangeRatePkg

{

    public interface IUSD_CLP_ExchangeRateFeed

    {

        int GetActualUSDValue();

    }

}

Listing 2

Now let's define the Calculator class to realize the ICalculator interface. Let's use Dependency Injection programming techniques to inject an object realizing the IUSD_CLP_ExchangeRateFeed interface using the constructor of the Calculator class. Finally, let's implement each method of the class (see Listing 3).

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using MoneyExchangeRatePkg;

namespace CalculatorPkg

{

    public class Calculator : ICalculator

    {

        private IUSD_CLP_ExchangeRateFeed _feed;

        public Calculator(IUSD_CLP_ExchangeRateFeed feed)

        {

            this._feed = feed;

        }

        #region ICalculator Members

        public int Add(int param1, int param2)

        {

            throw new NotImplementedException();

        } 

        public int Subtract(int param1, int param2)

        {

            throw new NotImplementedException();

        }

        public int Multipy(int param1, int param2)

        {

            throw new NotImplementedException();

        }

        public int Divide(int param1, int param2)

        {

            return param1 / param2;

        }

        public int ConvertUSDtoCLP(int unit)

        {

            return unit * this._feed.GetActualUSDValue();

        }

        #endregion

    }

}

Listing 3

Now let's prepare the testing environment for the Calculator component. We're going to use the NUnit testing framework and Moq mocking framework.

To get started with NUnit, you just need to download the framework from http://www.nunit.org/, and install it.

To get started with Moq, you just need to download the framework in a zip archive from http://code.google.com/p/moq/, and extract it to a location to reference the Moq.dll assembly from your testing environment.

Then, we create a testing library, add the references to NUnit and Moq frameworks, and add the tester class CalculatorTester to define the test cases.

Moq is very easy to use mocking framework. In order to define the mock objects, we use generics passing the interface as the type. The behavior of the mock objects is done using basically a set of lambda expressions, making the code more productive and type safe (see Listing 4).

Mock<IUSD_CLP_ExchangeRateFeed> mockObject = new Mock<IUSD_CLP_ExchangeRateFeed>();

mockObject.Setup(m => m.GetActualUSDValue()).Returns(500);

IUSD_CLP_ExchangeRateFeed value = mockObject.Object;

Listing 4

The final code for the testing cases is shown in the Listing 5.

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

// Step 1. Add a reference to the NUnit.Framework namespace

using NUnit.Framework;

// Step 2. Add a reference to the Moq namespace

using Moq;

// Step 3. Add a reference to the CalculatorPkg namespace

using CalculatorPkg;

// Step 4. Add a reference to the MoneyExchangeRatePkg namespace

using MoneyExchangeRatePkg;

namespace CalculatorPkg.Tests

{

    // Step 5. Add the attribute annotating the class as a tester

    [TestFixture]

    public class CalculatorTester

    {

        // Step 6. Add the definition of the mock objects

        private IUSD_CLP_ExchangeRateFeed prvGetMockExchangeRateFeed()

        {

            Mock<IUSD_CLP_ExchangeRateFeed> mockObject = newMock<IUSD_CLP_ExchangeRateFeed>();

            mockObject.Setup(m => m.GetActualUSDValue()).Returns(500);

            return mockObject.Object;

        }

        // Step 7. Add the test methods for each test case

        [Test(Description="Divide 9 by 3. Expected result is 3.")]

        public void TC1_Divide9By3()

        {

            IUSD_CLP_ExchangeRateFeed feed = this.prvGetMockExchangeRateFeed();

            ICalculator calculator = new Calculator(feed);

            int actualResult = calculator.Divide(9,3);

            int expectedResult = 3;

            Assert.AreEqual(expectedResult, actualResult);

        }

        [Test(Description = "Divide any number by zero. Should throw an System.DivideByZeroException exception.")]

        [ExpectedException(typeof(System.DivideByZeroException))]

        public void TC2_DivideByZero()

        {

            IUSD_CLP_ExchangeRateFeed feed = this.prvGetMockExchangeRateFeed();

            ICalculator calculator = new Calculator(feed);

            int actualResult = calculator.Divide(9, 0);

        }

        [Test(Description = "Convert 1 USD to CLP. Expected result is 500.")]

        public void TC3_ConvertUSDtoCLPTest()

        {

            IUSD_CLP_ExchangeRateFeed feed = this.prvGetMockExchangeRateFeed();

            ICalculator calculator = new Calculator(feed);

            int actualResult = calculator.ConvertUSDtoCLP(1);

            int expectedResult = 500;

            Assert.AreEqual(expectedResult, actualResult);

        }

    }

}

Listing 5

In this article, I've shown how to use Moq as the mocking framework in testing environments to isolate dependencies between objects in .NET solutions.