Monday, November 30, 2015

Getting started with Unit Testing and Moq

Part 1 you are here
Part 2
Part 3
Part 4

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:



 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
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:



 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
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



Posted by at
Labels: , , , , ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)