Day 1 of Software Architecture 2012 & Unit Test Patterns

This week I attended to Software Architecture 2012 conference from London. This was the first day of the conference and I decided to participate to a full day workshop about design patterns that was held by Andrew Clymer and Richard Blewett.
After this day I made a clearer image in my mind about some design pattern and how we can use it. There are a lot of new things that I discovered today. A part of them will be covered in future blog posts.
I looked over my today notes and I’m trying to extract some information for this blog post, but there are a lot of great things, that I feel the need to dedicate an entire post about it.
I will make only a small introduction into Unit Test Patterns. Any programmer should write unit tests. As we study design patterns in general we should learn also about unit test patterns.
In the last period of time the software industry become mature from many perspectives. The testing area, especially unit testing has reached his maturity. With this maturity, some pattern for unit testing appeared and guys don’t thing if you are a developer you should not know about this. This things are not for testers, are for you, for developers. Developers write unit test and not testers. Also understanding unit testing and pattern that are related to unit testing will improve our production code.
The simplest pattern is “Simple-Test”. This is the most basic unit test pattern that validate that for a valid input the expected outcome is obtained. In the case if our code contains an error trap, than we need to create a test for this case.
Suppose that we have a class Calculate that calculate the sum of two numbers. We will need to write a test that validate that the sum for two numbers is calculated correctly. This test will not guarantee that our code is valid and will work for any kind of input data. It only validate the most simple and basic happy flow.

public class Calculator
{
        public int Sum(int a, int b)
        {
            if (a == 0)
            {
                return b;
            }
            if (b == 0)
            {
                return a;
            }

            return a + b;
        }
}

[TestClass]
public class CalculatorTests
{
    Calculator calculator=new Calculator();

    [TestMethod]
    public void SumOfTwoSimpleNumbersReturnsTheSumOfNumbers()
    {
        Assert.AreEqual(10,calculator.Sum(2,8));
    }
}

Another well know pattern is “Code Path”. In the first pattern we didn’t look over the code. We tested it with the happy flow. The Code Path Pattern is used to test all the paths from our code. In this way, we will be more confident about out code quality. When we are writing this kind of unit tests we don’t look over the requirements, because we could miss some paths from our code. Code Path Pattern requires looking through the code in a “white box” method and covering all the possible paths. When we are using this pattern over legacy code you may be shocked about the number of lines of codes that are not used anymore.

[TestClass]
public class CalculatorTests
{
    Calculator calculator=new Calculator();

    [TestMethod]
    public void SumOfTwoSimpleNumbersReturnsTheSumOfNumbers()
    {
        Assert.AreEqual(10,calculator.Sum(2,8));
    }

    [TestMethod]
    public void SumWhenFirstNumberIsZeroReturnsSecondNumber()
    {
        Assert.AreEqual(5,calculator.Sum(0,5));
    }

    [TestMethod]
    public void SumWhenSecondNumberIsZeroReturnsFirstNumber()
    {
        Assert.AreEqual(3, calculator.Sum(3, 0));
    }

}

The last pattern that I will describe now is “Parameter Range”. When we are writing unit test, we should test our code with more than one input data. Even if we tested all the paths of our code this will not guarantee that our code is perfect.
For example in the previous example we should test what is happening if we calculate the sum of two big numbers that will generate a value that exceed the maximum value.

    [TestMethod]
    public void SumOfTwoSmallNumbersReturnsTheSumOfNumbers()
    {
        Assert.AreEqual(7, calculator.Sum(3, 4));
    }

    [TestMethod]
    public void SumOfTwoBigNumbersReturnsTheSumOfNumbers()
    {
        Assert.AreEqual(180, calculator.Sum(100, 80));
    }

    [TestMethod]
    public void SumOfTwoPrimeNumbersReturnsTheSumOfNumbers()
    {
        Assert.AreEqual(24, calculator.Sum(11, 13));
    }

I would like to congratulate the speakers of this workshop. I think that you made us thinking and see the design patterns from other perspectives.

Day 1

Day 2

Day 3

Day 4