What Is Your Philosophy on Unit Testing?

The purpose behind unit testing is to help ensure the code you have written performs as expected. The running of unit tests can be more effective when it is automated on a developers machine and as part of your CI/CD pipeline. Automated unit tests can also take the load off of limited QA resources by letting them focus on higher level testing (i.e. integration testing, regression testing, and acceptance testing).

Nowadays, when I’m handed a new code base to work on, I treat it as suspect. I have no idea if the code base will even run. If it does run, how do I know that it runs correctly? Unit tests will help me determine what shape the code base is in.

In general, I follow the red-green-refactor approach when writing unit tests. I write my tests in this order typically:

  1. Cover the happy paths through the code you are testing.
  2. Cover the upper and lower ends of inputs to your code.
  3. Cover any know edge cases known at the time.
  4. As a follow on to this process, if and when bugs are reported against code that I’m maintaining, I can then write a unit test to reproduce the bug and it will also tell me when it is fixed satisfactorily.

What unit testing framework do you like the best and why?


xUnit.net hands down. xUnit.net requires fewer attributes to set your tests up (i.e. Fact and Theory). Another feature I think is neat is using a class’s constructor (w/o any attributes) as a setup method for your unit tests. This is great because it follows the way classes work naturally.

What other unit testing frameworks have you used?


I have used NUnit and Visual Studio Unit Testing Framework (aka MSTest). I prefer NUnit to MSTest though.

What is the right amount of code coverage?


If I have to give a number, I would say between 70% and 80%. I would have a higher number for code that is heavily used and relied upon by other parts of the solution.

How would you go about writing unit tests?


I like using TDD on more complicated/intricate code because it let’s you work your way through the code step by step. I prefer a Given-When-Then (GWT) approach over Arrange-Act-Assert (AAA). The GWT approach allows you to write more human-readable unit tests. The AAA approach works, but is not as easily readable. In general, writing clear and understandable code is the goal. Here are a couple links that talk about GWT vs AAA:

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. Code for readability.

John Woods

What other tools can be used to improve unit tests?

What are some pitfalls of unit testing?

  • Testing the wrong thing – Software development teams need to make sure they are writing unit tests to cover code that they have written.
  • Getting lost in setup hell – This occurs when the setup for your unit tests starts to become tedious and takes a lot of time to get right. Using a GWT style seems to help with this.
  • “I’ll just comment out this unit test to get things working so I can check in my changes.” – I think this is just developers being lazy and apathetic about the changes being made to the solution. It is not a behavior I would encourage on my software development team.

So that’s my current philosophy on unit testing. What do you think? Am I wrong? Did I miss something? Feel free to post a comment or send me an email.

Thanks to Risa for the good question!

Task From A Code Test

Earlier this week I took a coding test and the first task in the test was interesting and alittle fun to complete. At the start you are given a text file with integers (one per line) that are used as an input into another process. This process has been failing because of problems with the input file. You are tasked with writing a program to validate the input files and output any errors to a separate file for use in troubleshooting. The task is to validate the file according to a set of rules.

The rules are as follows:
1.Verify that all integers in the file fall between 1 and N where N is the total number of lines in the text file.
2.Verify that all integers between 1 and N exist in the file (So if the file contains 3 lines, they should be 1, 2, and 3 in any order).
3.Output any errors to another file.

Rather than use a bunch of loops directly to iterate through the lines, I opted for a LINQ approach. Having done LINQ for so long, that approach usually looks better to me than writing the loops directly. The code is on GitHub and is available by clicking here.

Registering Types With the SimpleIoC Container

I’ve been kicking the tires on the Command Query Seperation principle/pattern lately. I’ve been using the CQS-Sample as a starting point. So far, the approach to breaking things down into Commands and Queries is pretty slick and much easier to unit test. The interfaces are used for dependency injection with an IoC container like SimpleIoC (which comes with MVVMLight). If you have done any work with IoC containers, you’ll know that you need to register your types with the container either explicitly or through some kind of convention. With a few classes it’s easy to just bang out the few lines of code you need to do it. In this case, the number of commands and queries is growing and having to explicitly register each one is becoming monotonous. So how to I register my queries and commands without having to write any code to explicitly register my types?

Assumptions:

  1. We are working with MVVMLight and SimpleIoC.
  2. For any query or command processor interface there is exactly 1 implementation of it.
  3. All queries are marked with an IQuery interface.
  4. All commands are marked with an ICommand interface (not to be confused with the System.Windows.Input.ICommand).
  5. All command processors implement ICommandProcessor<TCommand> where TCommand is a class that inherits from ICommand.

Step 1: Get an instance of MethodInfo for SimpleIoC’s Register<TInterface, TClass>() method.

Normally, getting the MethodInfo for a method you’d like to invoke is more straight forward. This method has 8 overloads so some LINQ was needed to get the correct one.

var registerMethodInfo = SimpleIoc.Default.GetType().GetMethods()
.Where(m => m.Name == "Register")
.Select(m => new
{
Method = m,
Params = m.GetParameters(),
Args = m.GetGenericArguments()
})
.Where(x => x.Params.Length == 0)
.Where(x => x.Args.Length == 2)
.Select(x => x.Method)
.First();

Step 2: Get a list of all types in the current AppDomain.

This step is pretty straightforward. Notice the .ToList() call at the end of method chain. This is to make sure that when we use types in the following steps, we won’t be enumerating the IEnumerable of types more than once.

var types = AppDomain.CurrentDomain.GetAssemblies().SelectMany(a => a.GetTypes()).ToList();

Step 3: Get all query interfaces that inherit from IQuery.

var queryInterfaces = from t in types
where t != typeof (IQuery)
where t.IsInterface
where typeof (IQuery).IsAssignableFrom(t)
select t;

Step 4: Create a query implementation class to query interface mapping

This step creates the query interface to query type mapping. The result is projected into an anonymous type that will be easy to use in the next step.

var queryMappings = from queryInterface in queryInterfaces
from t in types
where t.GetInterface(queryInterface.Name) == queryInterface
select new {queryInterface, Query = t};

Step 5: Register the query types

This is the last bit of reflection needed to register the queries. This code iterates of the query mappings from the previous step, gets a generic MethodInfo using the interface and implementation, and then invokes it on the current SimpleIoC instance.

foreach (var queryMapping in queryMappings)
{
var genericRegisterMethodInfo = registerMethodInfo.MakeGenericMethod(queryMapping.queryInterface, queryMapping.Query);
genericRegisterMethodInfo.Invoke(SimpleIoc.Default, null);
}

Step 6: Get a list of classes that inherit from ICommand.

var commands = from t in types
where t != typeof (ICommand)
where typeof (ICommand).IsAssignableFrom(t)
select t;

Step 7: Make the ICommandProcessor<T> interfaces.

This is an interesting step in the process. The command processors do not have a common non-generic interface, so we’ll have to make the generic type of ICommandProcessor<TCommand>.

 

var commandProcessorInterfaces = from command in commands
select new {CommandProcessorInterface = typeof (ICommandProcessor<>).MakeGenericType(command)};

Step 8: Map ICommandProcessor<T> interfaces to ICommandProcessor<T> implementations

Now we’ll create the mapping between the ICommandProcessor<TCommand>s and their implementations.

var commandProcessorMappings = from commandProcessorInterface in commandProcessorInterfaces
from t in types
where t.GetInterface(commandProcessorInterface.CommandProcessorInterface.Name) == commandProcessorInterface.CommandProcessorInterface
select new {commandProcessorInterface.CommandProcessorInterface, CommandProcessor = t};

Step 9: Register the command processor types

Same thing as step 5. Just iterating over the command mappings to make the generic MethodInfos and then invoking them on the current SimpleIoC instance.

foreach (var commandProcessorMapping in commandProcessorMappings)
{
var genericRegisterMethodInfo = registerMethodInfo.MakeGenericMethod(commandProcessorMapping.CommandProcessorInterface, commandProcessorMapping.CommandProcessor);
genericRegisterMethodInfo.Invoke(SimpleIoc.Default, null);
}

And that’s how I register all my command processors and queries through reflection. LINQ and Reflection FTW!

Are there better approaches? Sure. Are there better IoC containers out there? You betcha. But, this approach is Good Enough™ for now.

How to Detect Concurrent Events Using LINQ and Reactive Extensions

Here’s the scenario…

I have 3 referees around a powerlifting platform. Each has a set of 4 switches in their hand that is used to indicate if they thought a lift was good or not. One switch indicates the lift was good and the other 3 indicate the lift was no good and the general reason why. A referee’s light box displays the result by turning lights on and off. The individual lights should only turn on when all 3 referees have pushed their buttons. How do I determine when all 3 referees have pushed their buttons?

To get started, we need to create a simple event to indicate a referees decision.
public class RefereeDecisionEvent
{
public DateTimeOffset Timestamp { get; set; }
public DecisionCode Decision { get; set; }
}

The Decision property will hold a referee’s decision represented as a DecisionCode enumeration.

public enum DecisionCode
{
White = 0,
Red = 1,
Blue = 2,
Yellow = 4
}

White indicates the referee decided it was a good lift. Red, Blue, and Yellow represent potential reasons why the referee decided the lift was no good.

We’ll also need 3 event sources. Each event source represents a different referee; left, center, right. The actual implementation of the sources is outside the scope of this blog post. That said, I’ll just generate some events for each source at different intervals to give us some simple test data.

Step 1 is to join the left source’s events with the right source’s events. Since the left and right event sources create new events at different intervals, the events will most likely not occur at exactly the same time. We can fix this by increasing the duration of both sequences of events by 3 seconds. Now, we are joining the events from the left and the right sources when they occur within 3 seconds of each other.

var step1 = leftSource.Join(rightSource,
l => Observable.Interval(TimeSpan.FromSeconds(3)),
r => Observable.Interval(TimeSpan.FromSeconds(3)),
(l, r) => new {Left = l, Right = r});

Step 2 is to join the center source’s events with the now joined left and right side events. We’ll extend the durations of the events 3 seconds so that we can get a combined event that shows the left, center, and right events that all occurred withing 3 seconds of each other.

var step2 = centerSource.Join(step1,
l => Observable.Interval(TimeSpan.FromSeconds(3)),
r => Observable.Interval(TimeSpan.FromSeconds(3)),
(l, r) => new {r.Left, Center = l, r.Right});

In Step 3, we’ll project the results of step 2 into an event that is better laid out for our purposes. That Observable can then be subscribed to by an Observer that handles turning the lights on and off.

var step3 = from e in step2
select new
{
e.Left,
e.Center,
e.Right,
Status = new[] {e.Left.Decision, e.Center.Decision, e.Right.Decision}.Count(x => x == DecisionCode.White) >= 2 ? "Good" : "Bad"
};

And that’s how it’s done.

Simplifying Switches Using Dictionaries

Have you ever had to write a long series of if/then statements or a giant switch statement that extends for a page or two of your code? Want an easy way to increase the readability of your code, increase it’s maintainability index, and decrease it’s cyclomatic complexity? Let’s see an example problem and then a possible solution.

Let’s start off by considering the following array of anonymous types:

var items = new[]
{
    new {Operation = Operation.Add, Value1 = 1, Value2 = 2},
    new {Operation = Operation.Subtract, Value1 = 4, Value2 = 3},
    new {Operation = Operation.Multiply, Value1 = 5, Value2 = 6},
    new {Operation = Operation.Divide, Value1 = 8, Value2 = 4},
    new {Operation = Operation.Add, Value1 = 9, Value2 = 10},
    new {Operation = Operation.Subtract, Value1 = 12, Value2 = 11},
    new {Operation = Operation.Multiply, Value1 = 13, Value2 = 14},
    new {Operation = Operation.Divide, Value1 = 16, Value2 = 4},
    new {Operation = Operation.Add, Value1 = 17, Value2 = 18},
    new {Operation = Operation.Subtract, Value1 = 6, Value2 = 3},
    new {Operation = Operation.Multiply, Value1 = 8, Value2 = 8},
    new {Operation = Operation.Divide, Value1 = 10, Value2 = 2}
};

I need to iterate over this array and execute the given Operation on Value1 and Value2 properties to produce a list of results A brute force method of doing this is as follows:

var results = new List<int>();
 
foreach (var item in items)
{
    switch (item.Operation)
    {
        case Operation.Add:
            results.Add(item.Value1 + item.Value2);
            break;
        case Operation.Subtract:
            results.Add(item.Value1 - item.Value2);
            break;
        case Operation.Multiply:
            results.Add(item.Value1*item.Value2);
            break;
        case Operation.Divide:
            results.Add(item.Value1/item.Value2);
            break;
        default:
            throw new ArgumentOutOfRangeException();
    }
}

The switch statement is pretty straightforward and simple to implement in this example. Visual Studio 2013 Code Analysis is giving the code a maintainability index of 54 and a cyclomatic complexity of 6. What if I needed more lines of code to handle each operation? This could turn into a mess to test, debug, and maintain.

A possible solution to this problem is to replace your switch with a dictionary. I realize that seems odd to replace a control statement with a data structure, but refactoring to this approach will simplify your code. In our example, each item in the array has an Operation to be performed on the Value1 and Value2 properties. I can setup my dictionary with the key value being the Operation enumeration, and the value being the Action, Func, or method group that performs the operation.

var operationMethods = new Dictionary<Operation, Func<int, int, int>>
{
    {Operation.Add, Add},
    {Operation.Subtract, Subtract},
    {Operation.Multiply, Multiply},
    {Operation.Divide, Divide}
};

In the example above, I’m using the following methods:

public int Add(int left, int right)
{
    return left + right;
}
 
public int Subtract(int left, int right)
{
    return left - right;
}
 
public int Multiply(int left, int right)
{
    return left*right;
}
 
public int Divide(int left, int right)
{
    return left/right;
}

With the dictionary approach, our code to iterate over the items and execute the individual operations looks like this:

var results = new List<int>();
 
foreach (var item in items)
{
    results.Add(operationMethods[item.Operation].Invoke(item.Value1, item.Value2));
}

VS2013 gives the refactored code a maintainability index of 63 and a cyclomatic complexity of 2. Our code is still doing the same thing as the switch was, but we have broken the code down to simpler pieces that are more readable and more easily to wrap unit tests around.

I find this to be a good approach to take when the “cases” of our switch statement are known up front (such as using an enumeration). If it is possible that you will not have all the cases or keys in the dictionary, you can still use this approach but you will want to handle things more gracefully with the Dictionary’s TryGetValue method like so:

Func<int, int, int> operation;
 
if (operationMethods.TryGetValue(item.Operation, out operation))
{
    results.Add(operation(item.Value1, item.Value2));
}
else
{
// TODO: Handle case of the missing case/key
}

To tie it all together, here is a Gist with the code I discussed in this post.

I hope this helps. If you have any questions or comments, please use the comments form below. Thanks.