Getting started with Unit Testing and Moq — Part 1

I changed my RSS feed to medium over my blogger, and these keep popping up... so REPOST (though i may have changed some content) - also, oh dang, code snippets don't translate in between the two very well D:

“person using laptop in programming” by Steve Halama on Unsplash

We had a new team lead start recently, he seems to have had a fair amount of experience in areas I’m only vaguely familiar with, mostly through reading. One of the first things being pushed for is a concentration on unit testing. While I did begin implementing some tests into our codebase a few months ago (around 250 so far), I feel that there’s still a long way to go. Luckily Chris is here to help impart knowledge to us, hooray!

So getting started with unit testing — first it should be defined what a unit test is from https://en.wikipedia.org/wiki/Unit_testing :

In computer programming, unit testing is a software testing method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine whether they are fit for use.

Given the following classes/methods:

namespace  RussUnitTestSample.Business.Interface
{

    /// <summary>
    /// Interface to get some numbers from the database
    /// </summary>
    public  interface IDbGetSomeNumbers
    {

        /// <summary>
        /// Get an array of doubles from the database
        /// </summary>
        /// <returns></returns>
        double [] GetSomeNumbers ();
    }

    /// <summary>
    /// Interface for number functions
    /// </summary>
    public  interface INumberFunctions
    {
        /// <summary>
        /// Add numbers together
        /// </summary>
        /// <param name="numbers">The numbers to add.</param>
        /// <returns>The sum</returns>
        double  AddNumbers ( double [] numbers);
    }
}

namespace  RussUnitTestSample.Business
{

    /// <summary>
    /// Get numbers and then add them together
    /// </summary>
    public  class  GetNumbersAndAddThem
    {

        #region Private
        private  readonly IDbGetSomeNumbers _dbGetSomeNumbers;
        private  readonly INumberFunctions _numberFunctions;
        #endregion Private

        #region ctor

        /// <summary>
        /// Constructor - provide dependencies
        /// </summary>
        /// <param name="dbGetSomeNumbers">THe IDbGetSomeNumbers implementation.</param>
        /// <param name="numberFunctions">The INumberFunctions implementation.</param>
        public  GetNumbersAndAddThem (IDbGetSomeNumbers dbGetSomeNumbers, INumberFunctions numberFunctions)
        {
            if (dbGetSomeNumbers == null )
                throw  new  ArgumentNullException (nameof(dbGetSomeNumbers));

            if (numberFunctions == null )
                throw  new  ArgumentNullException (nameof(numberFunctions));

            this._dbGetSomeNumbers = dbGetSomeNumbers;
            this._numberFunctions = numberFunctions;
        }

        #endregion ctor

        #region Public methods

        /// <summary>
        /// Get the numbers and add them.
        /// </summary>
        /// <returns></returns>
public  double  Execute ()
        {
var numbers = _dbGetSomeNumbers.GetSomeNumbers();

return _numberFunctions.AddNumbers(numbers);
        }

        #endregion Public methods

    }

}

Note in the above, I am using interfaces to allow for the injection of dependencies (an important part of unit testing with mocks, and in general). The basic idea is you provide sample (unimportant) implementations to the dependent pieces of the whole, the pieces that are not currently being tested, therefore are unimportant to the test — at least when testing the “Put it all together” methods. I see the following things that need to be tested — there could very well be more, but here it is at a glance:

• INumberFunctions.AddNumbers
• IDbGetSomeNumbers.GetSomeNumbers
• GetNumbersAndAddThem.Execute

There are a few other stragglers in there that will become apparent (if they aren’t already) like null testing parameters in the constructor, testing empty array for add numbers, etc. For INumbersFunctions.AddNumbers, we need to of course, check the numbers are being added properly. I have accomplished that with the following tests:

using  System;
using  System.Diagnostics.CodeAnalysis;
using  System.Linq;
using  Microsoft.VisualStudio.TestTools.UnitTesting;

namespace  RussUnitTestSample.Business.Tests
{
    [TestClass]
    [ExcludeFromCodeCoverage]
    public  class  NumberFunctionTests
    {

        #region Public methods

        /// <summary>
        /// Test exception thrown when numbers provided is null
        /// </summary>
        [ExpectedException(typeof(ArgumentNullException))]
        [TestMethod]
        public  void  AddNumbers_NullParameterNumbers ()
        {
            // Arrange / Act / Assert
            NumberFunctions nf = new NumberFunctions();
            var result = nf.AddNumbers( null );
        }

        /// <summary>
        /// Test exception thrown when 0 numbers provided in array
        /// </summary>
        [ExpectedException(typeof(ArgumentException))]
        [TestMethod]
        public  void  AddNumbers_EmptyArrayNumbers ()
        {
            // Arrange / Act / Assert
            NumberFunctions nf = new NumberFunctions();
            var result = nf.AddNumbers( new  double [] { });
        }

        /// <summary>
        /// Add two positive numbers
        /// </summary>
        [TestMethod]
        public  void  AddNumbers_TwoNumbers ()
        {
            // Arrange
            double [] numbers = { 1 , 2 };
            NumberFunctions nf = new NumberFunctions();

            // Act
            var result = nf.AddNumbers(numbers);

            // Assert
            Assert.AreEqual(numbers.Sum(), result);
        }

        /// <summary>
        /// Add 10 numbers mixed positive and negative
        /// </summary>
        [TestMethod]
        public  void  AddNumbers_TenNumbersWithPositiveAndNegatives ()
        {
            // Arrange
            double [] numbers = { 1 , - 2 , 3 , 4 , - 5 , 6 , 7 , - 8 , 9 , 10 };
            NumberFunctions nf = new NumberFunctions();

            // Act
            var result = nf.AddNumbers(numbers);

            // Assert
            Assert.AreEqual(numbers.Sum(), result);
        }

        [TestMethod]
        public  void  AddNumbers_ProvideOneNumber ()
        {
            // Arrange
            double [] numbers = { 1 };
            NumberFunctions nf = new NumberFunctions();

            // Act
            var result = nf.AddNumbers(numbers);

            // Assert
            Assert.AreEqual(numbers.Sum(), result);
        }

        #endregion Public methods
    }
}

There is most definitely some overlap in some of the tests, but with something so simple there’s still quite a few! I don’t feel the actual implementation of NumberFunctions is important, as I’m concentrating on the tests. That takes care of the class that has completed non Moqed tests. In the next post (which I will hopefully do soon) I’ll go into how I accomplished my first unit tests with Moq. If I can get a well enough cadence going on, I hope to cover Moqing WCF service calls — as that’s what we use at work for our communication to our DB, so being able to moq that as well would be beneficial.

Full code including the Moq unit tests can be found at: https://github.com/Kritner/RussUnitTestSample

Originally published at kritner.blogspot.com on November 30, 2015.