In this post I will show how to make testable something that ( at least me ) usually left as untested. I’m talking about the preparing phase of a console app, the checking arguments error reporting and so on. That logic is usually so simple that any good cow boy programmer would probably leave outside any unit testing. Unfortunately we should at least do some manually check that prove that logic working, and doing things manually is always silly. In this post we assume we have a working command line parsing library, and a mocking framework. Let see the cowboy code:

        static void Main(string[] args)
        {
            string optA,optB;
            optA = optB = null;
            bool done = false;
            OptionSet set = new OptionSet();
            set.Add("a=", (k) => optA = k);
            set.Add("b=", (k) => optB = k);
            set.Add("h", (k) => { LongHelp(); done = true; });
            set.Parse(args);
            if (done)
                return;
            if (string.IsNullOrEmpty(optA) || string.IsNullOrEmpty(optB))
            {
                ShortHelp();
                return;
            }
            DoTheJob(optA,optB);
            
        }

        private static void DoTheJob(string optA, string optB)
        {
            //something interesting here
        }

        private static void LongHelp()
        {
            Console.Error.WriteLine("Long help here...");
        }

        private static void ShortHelp()
        {
            Console.Error.WriteLine("Short help here");
        }
    }

So nothing special, the example is actually very simple, we have two mandatory parameters, a command line switch to print a long help. If one argument is missing a short help line must be presented. If all the parameters are provided, the DoTheJob() method should be called with the correct values.

Current code is not testable without hosting the console application as a process, and looking at the stdout to see what happen. Even by this strategy, we can not punctually check what is passed to DoTheJob. So we want to refactor the code, without adding any complexity to the app. So here below the proposed refactoring:

    public class Program
    {
        static void Main(string[] args)
        {
            new Program().Run(args);
        }
        public virtual void Run(string[] args)
        {
            string optA, optB;
            optA = optB = null;
            bool done = false;
            OptionSet set = new OptionSet();
            set.Add("a=", (k) => optA = k);
            set.Add("b=", (k) => optB = k);
            set.Add("h", (k) => { LongHelp(); done = true; });
            set.Parse(args);
            if (done)
                return;
            if (string.IsNullOrEmpty(optA) || string.IsNullOrEmpty(optB))
            {
                ShortHelp();
                return;
            }
            DoTheJob(optA, optB);

        }

        public virtual void DoTheJob(string optA, string optB)
        {
            //something interesting here
        }

        public virtual void LongHelp()
        {
            Console.Error.WriteLine("Long help here...");
        }

        public virtual void ShortHelp()
        {
            Console.Error.WriteLine("Short help here");
        }
    }

So pretty easy, we provide a non static method Run(), and all the internal function are declared virtual. This is a five minutes modification we could probably apply to any other code like this we have. The difference is that we can write some unit test, lets see how:

        [TestMethod]
        public void ShouldDisplayShortHelp()
        {
            var moq = new Mock
(); moq.CallBase = true; moq.Setup(k=>k.DoTheJob(It.IsAny
(),It.IsAny
())) .Throws(new InvalidProgramException("Should not call")); moq.Object.Run(new string[0]);
moq.Verify(k => k.ShortHelp()); } [TestMethod] public void ShouldDisplayLongHelp()
{ var moq = new Mock
(); moq.CallBase = true; moq.Setup(k => k.DoTheJob(It.IsAny
(), It.IsAny
())) .Throws(new InvalidProgramException("Should not call")); moq.Object.Run(new string[]{"-h"});
moq.Verify(k => k.LongHelp()); } [TestMethod] public void ShouldInvokeWithProperParameters()
{ var moq = new Mock
(); moq.CallBase = true; moq.Setup(k => k.DoTheJob("p1", "p2")).Verifiable(); moq.Object.Run(new
string[] { "-a=p1","-b=p2" }); moq.Verify(); } 

I used the MoQ library, please note the Callbase set to true, because we are using the same object for driving and for expect calls. So in conclusion, we achieve a real unit test of something we sometimes left apart, we did that in memory, and even if the example is really trivial, the concept can be used in complex scenarios too. What about testing the inside part of DoTheJob()? well, if a good testing strategy is used, the internal part should be testable outside somewhere else, here we are  proving we can test the shell. 

This is a post for myself, because I’m much more a cow boy programmer, and I know this is bad, even if sometimes results are apparently good. The leaking part in my code are usually unit tests, and there is no excuse about that, since it is necessary to change the approach on its root, for example writing the (failing) test before the real code. This is actually a design strategy, that eventually improve the reliability of the software and the portability of the software against other developers. The hardest part is that sometimes the boundary between unit testing and integration testing is apparently very thin: making that boundary better defined is part of the design process. I found this document, and I think is very useful to understand the common errors producing a non testable code, and the strategy to avoid them.

Sometimes happens that we need to roll over all the combinations of elements in multiple arrays. This operation is called Cartesian Product and is defined as:

Definition (Cartesian product): Let A₁, ..., A_n be n sets.

Then the set of all ordered n-tuples <x₁, ..., x_n> , where x_iA_i for all i, 1in ,

is called the Cartesian product of A₁, ..., A_n, and is denoted by A₁ ... A_n .

Achieving this is possible by some linq tricks, or by an helper class I propose in this post. But just for clarify let’s start from the example:

We have three array as below:

 { "JUICY", "SWEET" }

{ "GREEN", "YELLOW" }

{ "APPLE", "BANANA", "MANGO" }

we want to obtain all the possible tuples, ie:

This can be achieved by the following code ( helper class ):

          public class 
          CartesianProduct<T>
{ int[] lengths; T[][] arrays; public CartesianProduct(params T[][]
arrays) { lengths = arrays.Select(k => k.Length).ToArray(); if (lengths.Any(l
=> l == 0)) throw new ArgumentException("Zero
lenght array unhandled."); this.arrays = arrays;
} public IEnumerable<T[]>
Get() { int[] walk = new
int[arrays.Length]; int x = 0; yield
return walk.Select(k => arrays[x++][k]).ToArray(); while (Next(walk))
{ x = 0; yield return walk.Select(k => arrays[x++][k]).ToArray();
} } private bool Next(int[]
walk) { int whoIncrement = 0; while (whoIncrement
< walk.Length) { if (walk[whoIncrement] < lengths[whoIncrement]
- 1) { walk[whoIncrement]++; return true; } else {
walk[whoIncrement] = 0; whoIncrement++; } } return false;
} } 

And, just for completeness, the example application:

          static void Main(string[]
args) { var cross = new CartesianProduct<string>( new
string[] { "JUICY", "SWEET" }
, new string[] { "GREEN", "YELLOW" }
, new string[] { "APPLE", "BANANA", "MANGO" }
); Console.WriteLine("========================================================="); foreach (var item in cross.Get())
{ Console.WriteLine("{0}\t{1}\t{2}",
item[0], item[1], item[2]); } Console.WriteLine("=========================================================");
}