<charliedigital /> Programming, Politics, and uhh…pineapples

FluentNHibernate And NHibernate.Linq

Posted by Charles Chen

Just a little blurb on FluentNHibernate and NHibernate.Linq.

I've been working through the samples for FNH and decided to try out some different query scenarios to see how the queries would be generated. I stumbled a bit on the first rather simple scenario: selecting an item based on the total count of related items. In this case, from the FNH demo, I wanted to select "all stores with more than 2 employees". Seems like a simple enough query, right?

You can see from the full code that this should return "Bargain Basement". However, in going through the documentation, it wasn't exactly apparent how this could be done; it seemed a lot more convoluted than necessary using criteria queries and it simply wasn't working. Via Google, I came across a blog post that mentioned using either DetachedCriteria or HQL. Quite frankly, neither was very appealing.

So I figured I'd download NHibernate.Linq and see if it would be better. Not knowing what I would get, SQL-wise, I wrote the following query:

using (session.BeginTransaction())
{
    IQueryable<Store> stores = from s in session.Linq<Store>()
                               where s.Staff.Count > 2
                               select s;

    foreach (Store store in stores)
    {
        Console.WriteLine("STORE: {0}", store.Name);
    }
}

Of course, the interesting question is whether the the Staff list would be loaded to perform the count and to my pleasant surprise, it was not. Here's the query in profiler (reformatted for legibility):

exec sp_executesql N'
    SELECT 
        this_.Id as Id1_0_, 
        this_.Name as Name1_0_ 
    FROM 
        [Store] this_ 
    WHERE 
        @p0 <   (
                SELECT 
                    count(staff1_.Id) as y0_ 
                FROM [Store] this_0_ 
                    left outer join [Employee] staff1_ 
                        on this_0_.Id=staff1_.Store_id 
                WHERE 
                    this_.Id = this_0_.Id
                )',N'@p0 int',@p0=2

Sweet! The framework correctly builds a sub-select query to count the staff members.

I guess I'm just easy to impress but I'm digging it.

I think what I like about FluentNHibernate the most is that I can stop building database applications. What I mean by this is an application built from the database up. The main issue this raises is complexity with regards to mapping to a data layer and of course continuously having to synchronize your DDL and SQL with your class files. The following code configures the database, including dropping and creating the tables based on mapping classes in my assemblies:

private static ISessionFactory CreateSessionFactory()
{
    return Fluently.Configure()
        .Database(
        MsSqlConfiguration.MsSql2008.ConnectionString(
            @"Data Source=SCOOBY;Initial Catalog=FluentNHDemo;
            Integrated Security=SSPI;Application Name='FNHDemo'"))
        .Mappings(m =>
                  m.FluentMappings.AddFromAssemblyOf<Store>())
        .ExposeConfiguration(BuildSchema)
        .BuildSessionFactory();
}

private static void BuildSchema(Configuration config)
{
    // this NHibernate tool takes a configuration (with mapping info in)
    // and exports a database schema from it
    SchemaExport schema = new SchemaExport(config);

    schema.Drop(false, true); // Drops the tables only.
    schema.Create(false, true);
}

With no mapping files to speak of, persistence plumbing becomes trivial and I can work entirely within Visual Studio. Of course, for complex queries and queries that need to be highly performant, you may still be better off writing stored procedures (as I've advocated in the past), but the productivity gains to be had can't be ignored and I find the compile-time validation of the queries eases some of my indifference towards dynamic SQL.

Chain Of Command And Passing Parameters

Posted by Charles Chen

One of the more useful patterns that I've used quite frequently is a version of Chain of Responsibility that integrates with the Command pattern. In a classic CoR, the idea is that only one component in the chain handles the request and then execution flows out of the chain. In a CoC pattern, the idea is that the execution flows through the entire chain.

I like Shahan Khatchadourian's description of this pattern:

When programming, certain sections of code can sometimes be viewed as a workflow or preset sequence of tasks or commands. This can considered to be the design pattern called Chain of Command...

There are two key problems that this pattern solves that make it immensely useful in everyday programming (it's a bit surprising that dofactory's listing of CoR lists the frequency of use as a 2/5).

The first problem that it solves is extensibility. By implementing the chain as a list of abstract types (Command or Validator or whatever), using reflection (one way or another), you can build a list of concrete commands, giving each element in the chain a chance of working on the input request. One example of how I use this is to implement validation where I might have an abstract base class called Validator. To build the chain of validators, one very quick and easy solution is to reflect on the assembly and simply find all of the classes which implement Validator (additional complexity can be added as necessary, such as supporting validators in external assemblies or different groupings of validators).

The second (related) problem that it solves is excessively large blocks of if statements. In a validation example, you can imagine that if it were written in-line, each validation rule would essentially map to an if statement in a large block. In a way, it's a very useful pattern for exchanging a tiny bit of performance and memory for more modular organization of logic. Without the CoC pattern, adding a new validation rule would mean adding another if block - yuck! Using CoC with reflection, we can simply add another class which inherits Validator to our project and count on the component building the chain to find our class and add it to the chain.

Here is a very simple, barebones implementation:

/// <summary>
/// A simple command chain factory that doesn't do wiring.
/// </summary>
public static class SimpleCommandChainFactory
{
    /// <summary>
    /// Creates a simple list of commands to execute using reflection.
    /// </summary>
    public static List<Command> Create()
    {
        var commands = new List<Command>();

        Type[] types = Assembly.GetExecutingAssembly().GetTypes();
        Type commandType = typeof (Command);

        foreach (Type type in types)
        {
            if (!type.IsSubclassOf(commandType))
            {
                continue;
            }

            MemberInitExpression init = Expression.MemberInit(
                Expression.New(type), new MemberBinding[0]);

            Command command = Expression.Lambda<Func<Command>>(init)
                .Compile().Invoke();

            commands.Add(command);
        }

        commands = commands.OrderBy(c => c.Priority).ToList();

        return commands;
    }
}

The code checks to see if a type if a sub-type of Command and, if so, creates an instance and puts it on the chain. The commands could then be executed like so:

internal class Program
{
    private static void Main(string[] args)
    {
        List<Command> commands = SimpleCommandChainFactory.Create();

        // Execute each command.
        foreach(Command command in commands)
        {
            command.Execute();
        }
    }
}

In this case, I'm not passing in data or checking for stop conditions (which might be useful in a validation scenario where the first failure stops processing). To do so, you could simply pass in a single instance of some context class to each command when executing and check to see if the stop condition is true after the execute call (and break out of the for-loop).

While this pattern is immensely useful any time you find a big if or switch block that's particularly volatile, one problem that I've found with this pattern is passing parameters between two elements in the chain. Ideally, no element in the chain should have a dependency on another element in the chain. We want to decouple each of the elements to make it easier to build the chain dynamically. What this means is that no element should directly set values on another element in the chain. In essensce, to emulate the functionality of DependencyObject and DependencyProperty that we find in WF and WPF. (Why not just use WF then? Complexity and performance.)

At least two solutions come to mind. The first is to pass a context with a dictionary through each element of the chain. This would allow each element to place an output value into the dictionary and downstream components to pull these values out. The downside of this approach is that unless you force everything into one value type (i.e. serialize to an XML string?), you can't really pass strongly typed data and now you're keyed by strings (or whatever value type) which you need to have know about in order to retrieve the value.

A second approach would be to leverage DependencyObject and DependencyProperty. While this sounds good in principle, it requires a mess of code to accomplish in your own code with your own objects. Not only that, it seems to be overkill since many times, you don't need the full capabilities of the dependency system - you just want to pass a value downstream in a nice, strongly typed manner.

(There is a third approach using thread local storage, but this is probably an even worse option than the first since it wouldn't be very accessible to most developers and it doesn't really address the issue at hand.)

In the past, I've relied on the dictionary based approach. While it wasn't ideal, it was the simplest solution that got the job done. Deep down, I always hated this approach because I didn't like having to know the keys and having to know how to cast the results retrieved from the dictionary. However, I recently came up with a much better solution to this issue: dynamically wired events.

We introduce two attribute classes which we can use to identify our event publishers and event subscribers. For brevity, I'll only show the publisher attribute (they are pretty much the same in this implementation):

/// <summary>
/// Attribute used to identify event publishers.
/// </summary>
[AttributeUsage(AttributeTargets.Event)]
public class EventPublisherAttribute : Attribute
{
    private readonly string _eventName;

    /// <summary>
    /// Initializes a new instance of the <see cref="EventPublisherAttribute"/> class.
    /// </summary>
    /// <param name="eventName">Name of the event.</param>
    public EventPublisherAttribute(string eventName)
    {
        _eventName = eventName;
    }

    /// <summary>
    /// Gets the name of the event.
    /// </summary>
    /// <value>The name of the event.</value>
    public string EventName
    {
        get { return _eventName; }
    }
}

The only difference between the two in this case is the AttributeUsageAttribute. In the case of the subscriber, we want it to apply to methods, not events. Next, we need to apply these attributes to our concrete command types that we're going to chain. For this example, let's say that the first item in the chain generates a GUID key that the rest of the items in the chain also need to use:

/// <summary>
/// Generates a GUID that may be needed by the rest of the chain.
/// </summary>
public class GenerateKeyCommand : Command
{
    /// <summary>
    /// Raised when a key is generated;
    /// </summary>
    [EventPublisher(EventNames.KeyGenerated)]
    public event EventHandler<EventArgs<Guid>> KeyGenerated;

    /// <summary>
    /// Executes this instance.
    /// </summary>
    public override void Execute()
    {
        Guid key = Guid.NewGuid();

        Console.Out.WriteLine("From GenerateKeyCommand: {0}", key);

        OnKeyGenerated(key);
    }

    /// <summary>
    /// Gets the priority.  A lower value indicates higher priority.
    /// </summary>
    /// <value>The priority.</value>
    public override int Priority
    {
        get { return 1; }
    }

    /// <summary>
    /// Raises the key generated event.
    /// </summary>
    /// <param name="key">The key.</param>
    private void OnKeyGenerated(Guid key)
    {
        if(KeyGenerated != null)
        {
            KeyGenerated(this, new EventArgs<Guid>(key));
        }
    }
}

As you can see, it's pretty standard stuff, with the exception of the additional attribute on the event. Downstream, we want to handle these events in other commands:

/// <summary>
/// Simple command just for demonstration purposes.
/// </summary>
public class DoSomethingWithKeyCommand : Command
{
    private Guid _key;

    /// <summary>
    /// Executes this instance.
    /// </summary>
    public override void Execute()
    {
        Console.Out.WriteLine("From DoSomethingWithKeyCommand: {0}", _key);
    }

    /// <summary>
    /// Gets the priority.  A lower value indicates higher priority.
    /// </summary>
    /// <value>The priority.</value>
    public override int Priority
    {
        get { return 100; }
    }

    [EventSubscriber(EventNames.KeyGenerated)]
    private void HandleKeyGenerated(object sender, EventArgs<Guid> e)
    {
        _key = e.Data;
    }
}

You can see that in the event handler method, we just grab the value from the event arguments and set it on a local variable for use when Execute() is called.

Now the trick is to wire these events up using reflection to avoid creating the direct dependency between the different elements in the chain. Spring.NET offers one way to do this using declarative events, however, it should be noted that it only works with singleton objects (this bit me in the butt until I figured it out). Depending on the nature of your elements in the chain, that may or may not be sufficient for you. If you need new instances every time, then we can accomplish this ourselves using a bit of reflection.

(Note that none of the code that follows has been optimized; there are a few caching opportunities to take advantage of to cut down on some of the reflection calls.)

The first step is to modify the factory method:

/// <summary>
/// Creates a command chain using reflection.
/// </summary>
/// <returns></returns>
public static List<Command> Create()
{
    List<Command> commands = new List<Command>();

    Type[] types = Assembly.GetExecutingAssembly().GetTypes();
    Type commandType = typeof (Command);

    Dictionary<string, List<EventCoupling>> eventSources
        = new Dictionary<string, List<EventCoupling>>();

    Dictionary<string, List<MethodCoupling>> eventTargets
        = new Dictionary<string, List<MethodCoupling>>();

    foreach(Type type in types)
    {
        if(!type.IsSubclassOf(commandType))
        {
            continue;
        }

        MemberInitExpression init = Expression.MemberInit(
            Expression.New(type), new MemberBinding[0]);

        Command command = Expression.Lambda<Func<Command>>(init)
            .Compile().Invoke();

        commands.Add(command);

        BuildHandlerCache(command, eventTargets, 
            type.GetMethods(_methodFlags));

        // Parse the events.
        EventInfo[] events = type.GetEvents(
            BindingFlags.Public | BindingFlags.Instance);

        if(events.Length == 0)
        {
            continue; 
        }

        BuildEventCache(command, eventSources, events);
    }

    WireEvents(eventSources, eventTargets);

    commands = commands.OrderBy(c => c.Priority).ToList();

    return commands;
}

We create two caches as we iterate through the types to hold the events and handler methods that we encounter as we iterate the types and as a final step, we wire the events together from the caches. The cache building logic is fairly straightforward:

/// <summary>
/// Builds the handler cache.
/// </summary>
/// <param name="command">The command.</param>
/// <param name="eventTargets">The event targets.</param>
/// <param name="methods">The methods.</param>
private static void BuildHandlerCache(
    Command command, 
    IDictionary<string, List<MethodCoupling>> eventTargets, 
    IEnumerable<MethodInfo> methods)
{
    foreach(MethodInfo method in methods)
    {
        EventSubscriberAttribute[] subscriberAttributes =
            (EventSubscriberAttribute[])
            method.GetCustomAttributes(
                typeof(EventSubscriberAttribute), false);

        if (subscriberAttributes.Length == 0)
        {
            continue;
        }

        foreach(EventSubscriberAttribute attribute in subscriberAttributes)
        {
            if(!eventTargets.ContainsKey(attribute.EventName))
            {
                eventTargets[attribute.EventName] = new List<MethodCoupling>();
            }

            eventTargets[attribute.EventName].Add(
                new MethodCoupling(method, command));
        }
    }
}

/// <summary>
/// Builds the event caches.
/// </summary>
/// <param name="command">The command.</param>
/// <param name="eventSources">The event sources.</param>
/// <param name="events">The events.</param>
private static void BuildEventCache(
    Command command,
    IDictionary<string, List<EventCoupling>> eventSources,  
    IEnumerable<EventInfo> events)
{
    foreach(EventInfo eventInfo in events)
    {
        EventPublisherAttribute[] publisherAttributes =
            (EventPublisherAttribute[])
            eventInfo.GetCustomAttributes(
                typeof (EventPublisherAttribute), false);

        if(publisherAttributes.Length == 0)
        {
            continue;
        }

        foreach (EventPublisherAttribute attribute in publisherAttributes)
        {
            if(!eventSources.ContainsKey(attribute.EventName))
            {
                eventSources[attribute.EventName] = new List<EventCoupling>();
            }

            eventSources[attribute.EventName].Add(
                new EventCoupling(eventInfo, command));
        }
    }
}

The gist of it is that we want to iterate through the events and the methods, find the ones with the attributes, map them to instances of commands, and throw them into a dictionary. As you can see, the dictionary values are generic lists on both sides; this means that a single event can fire multiple event names and a single handler method can handle multiple events (as long as the method input types are the same). This may or may not be useful in any given scenario, but it's easy enough to rewrite this to make it a bit simpler if it's not required.

Finally, we need to wire the events together in the chain after it's created:

private static void WireEvents(
    Dictionary<string, List<EventCoupling>> eventSources,
    Dictionary<string, List<MethodCoupling>> eventTargets)
{
    foreach(string key in eventSources.Keys)
    {
        if(!eventTargets.ContainsKey(key))
        {
            continue;
        }

        List<MethodCoupling> targets = eventTargets[key];
        List<EventCoupling> sources = eventSources[key];

        foreach(EventCoupling source in sources)
        {
            foreach(MethodCoupling target in targets)
            {
                Delegate d = Delegate.CreateDelegate(
                    source.Event.EventHandlerType,
                    target.Command,
                    target.Method);

                source.Event.AddEventHandler(source.Command, d);
            }
        }
    }
}

It's as simple as that: we loop through each event (publishers) and see if there is a list of methods (subscribers) to handle it in the chain. If so, we add a delegate as a handler to the event. In my sample project, I created three simple command types to demonstrate; here's the output when I run my program:

You can see, once the key is generated in the first command, the value is available in the downstream commands using the events. The nice thing is that we can add more steps to our logic without much extra work. This is particularly handy for something like implementing a chain of validation rules as it means that you don't end up writing a big if if block. But even in general usage, this pattern is useful for breaking out a large method into smaller, more modular pieces in a much more extensible manner.

One neat thing is that it allows you to not only wire events downstream, but also upstream as well. This means that if an element in your chain triggers an event, code in a previous even is executed if there is a handler wired for it.

In a more complete implementation, you may consider using Spring.NET or Unity or simply .NET configuration to statically identify the elements of the chain (instead of the basic reflection I've used). You may also consider more error handling logic and passing an instance of a context through each element in the chain.

The full sample project is available here: ChainOfCommandSample.zip (11.21 KB)

Yet Another .NET Interview Questions List

Posted by Charles Chen

There are tons of blog posts on .NET interview questions out there on the 'Net; here's another list...just because I feel like it, okay ?

In general, when I am interviewing people, I don't go for the obvious questions.  Not only are they boring because I've answered them so many times, but most of them can be easily studied for.  For most C#/.NET positions, there's a pretty standard set of questions that you'll encounter, most of which can be easily answered by simply reading Troelsen's Pro C# (I know because I picked it up the first time I was burned after a phone screen - I recommend this book to all junior developers looking to move up the payscale).

I do incorporate a few "template" questions, but in general, I like to keep things away from fact based questions and geared towards open-ended questions (I want to see that a candidate has actually done more than just use a feature after looking it up on MSDN or whatever - I want to see that a developer has actually sat there and thought about the technology or feature or whatever).

Here are a few of my favorite questions for interviews; perhaps you'll find them useful for your own interviews:

[ASP.NET] Discuss the strengths and weaknesses of ASP.NET, out of the box.

I ask this question because I want to see if a developer has thought really thought about ASP.NET as a framework.  Developers who have can answer this pretty easily.  Developers who just write the code and move on will give some really perplexing answers or flat out stumble on this one.  I like this question because it's completely open-ended and a developer is free to use anything in his/her past experience as a context.  Some developers may compare and constrast it to other frameworks they've used (ASP, JSP, Python, Ruby, etc).  Some will describe past frustrations or projects as points of reference for weaknesses.  In general, I like this question because it shows whether an individual can discuss the technology intelligently.

[ASP.NET] What's the difference between an HtmlControl and a WebControl?

What I'm looking to find out with this question is whether a candidate can show some restraint with regards to using web controls on a page where an HTML control would work just as well.

[ASP.NET] Can you describe any approaches or patterns to make ASP.NET web forms programming more manageable?

In the simplest case, I'd like to hear something like "In the past, I've implemented MVC" or any sort of presenter/controller-view style pattern or - at the least - "I've created a custom base class which inherits Page", to show that the developer won't be inclined to just throw a bunch of code in the codebehind and call it a day.  One common answer is some variation of "I use an N-tier approach", but I find this answer to be insufficient since an N-tier approach doesn't mean much in terms of ensuring that your UI code is clean and well organized.  Developers who mostly think of ASP.NET as drag-drop-fill in code will never be able to give any sort of satisfactory answer to this question.

[.NET] How many major versions of the .NET runtime have there been?

Okay, this one is kind of a "gotcha" question, I admit, but it is relevant for a couple of reasons.  Developers who follow up on blogs and stay current will undoubtedly know that there is a new version of the runtime shipping with the next release of VS/.NET.  Developers who have worked extensively with ASP.NET will also know that in IIS, you can only select from 1.x or 2.x versions of the runtime.  I don't think anyone has gotten this one right yet, even though I put a particular emphasis on "runtime" when reading the question.

[.NET] What access modifier does Microsoft recommend for constructors on abstract classes?

What I'm hoping for is to one day hear: "Well, according to Framework Design Guidelines..." (or something equivalent).  The goal of the question is to see if a candidate understands some of the nuances of API and framework design, especially important for senior developer roles.  There are other questions along this vein, one of my other favorites is...

[.NET] What does the following code statement imply?

Again, the goal is to see how well a candidate understands the implications of their design decisions and some basic C#.  I won't give up on a candidate if they get it wrong; I try to coax them the correct conclusion, but few candidates can right the course once they make up their mind on this one.

If they bring up ReadOnlyCollection, they get bonus points.

[.NET] Can you expose abstract classes in an ASMX or WCF service contract?

This question can, answered correctly, indicate an above average level of understanding of .NET web services but, more importantly, I think it offers a peek at whether a candidate embraces object oriented design principals.  Candidates who have designed or worked with systems with rich object models will have undoubtedly encountered this problem (unless there were some specific interoperability scenarios which they had to design around).

[.NET] What is a custom attribute and how can you read one?

This question can reveal a lot about a candidate since there are some design scenarios that can be resolved pretty elegantly by taking advantage of custom attributes.  In addition, a candidate that can answer this question necessarily has experience working with reflection.  With regards to the second part, I'm not looking for specifics in terms of syntax and namespaces and classes, but rather a generic answer like "By using reflection" or something.

[.NET] What is the default() statement used for?

This is more of a textbook question, but candidates who have worked extensively with generics will be able to answer this with ease.  Again, being able to answer this reveals a lot about a candidate, especially when considering one for a senior developer position since being able to leverage generics is a big part of writing a solid API or framework.

[.NET] Desribe your approach to exception handling.

Another open-ended question that allows a candidate to shine - or to flail.  I've heard a wide range of responses to this one, but none that indicate that a developer has put any significant thought into one of the most important aspects of writing code on the .NET platform (especially framework level code).  Most responses fall into the basic structural elements of exception handling (try-catch-finally), but I am looking forward to the day that someone gives a response which addresses it at a much higher level than that.

[GENERAL] What is object oriented programming?

I usually preface this by stating that I'm not looking for the bullet-list textbook definition of it; I'm looking for a candidate to provide a much deeper answer than that.  There's no "right" answer, but there are definitely bad answers or responses (I've heard some wacky ones) that reveal that a candidate hasn't really thought deeply about just what it means to write good object oriented code.  To me?  Aside from the textbook stuff, OOP is about modeling complexity using structural interactions instead of straight-line, imperative logic.

This is just a small slice of my list, but they are perhaps the most important ones with regards to ASP.NET/C#, IMO.  What do you think?  Too abstract?  Too high level?  Too awesome ?  Hopefully, you've found something useful in here, either as an interviewer or an interviewee.

MbUnit CsvDataAttribute

Posted by Charles Chen

MbUnit has several cool features which distinguish it from some of the other unit testing frameworks on the .NET platform. Among them are the RollbackAttribute, PrincipalAttribute, ThreadedRepeatAttribute, and the Csv/XmlDataAttribute.

I hadn't noticed the CsvDataAttribute previously when I've worked with MbUnit, but it's definitely one that I think that most teams can make the most use of. While the RowAttribute allows developers to externalize and parameterize their unit tests, the CsvDataAttribute takes it to another level by allowing developers to put test parameters in a simple text file. This is extremely handy since it becomes easier to add more test conditions as you come up with new scenarios without recompiling code. Theoretically, you could even involve your QA team in getting the right set of test data since they could modify the external CSV file. I find this extremely handy

The documentation on how to use it was lacking a bit; while it explained that you can add metadata (custom attributes) via the CSV file, it didn't give an example for the ExpectedExceptionAttribute, one of the most common ones, I'd imagine.

Consider the following property which normalizes and validates a phone number (note: this was meant as a simple example):

/// <summary>
/// Gets or sets the number.
/// </summary>
/// <value>The number.</value>
public string Number
{
    get { return _number; }
    set
    {
        if (string.IsNullOrEmpty(value))
        {
            throw new ArgumentException(
                "The phone number cannot be null or empty.");
        }

        // Grab all the digits.
        char[] digits = value.ToCharArray()
            .Where(c => char.IsDigit(c)).ToArray();

        if (digits.Length != 10)
        {
            throw new FormatException(
                "A phone number must contain 10 digits.");
        }

        _number = new string(digits);
    }
}

The test method might look like this:

[Test]
[CsvData(FilePath = "CsvData\\PhoneNumbers.txt", HasHeader = true)]
public void TestPhoneNumberNormalizationWithCsv(
    string type, string number, string expected)
{
    PhoneNumber phoneNumber = new PhoneNumber(0, 0, number, type);

    Assert.AreEqual(expected, phoneNumber.Number);
}

Now we'd like to test our validation logic to gaurd against future refactorings to make sure that anyone refactoring this code throws the appropriate exceptions that our downstream callers expect.

You can see that I've used the FilePath property and the HasHeader property (you have to use this if there is a header, otherwise, it detects the header as a row; it's not true by default it seems). The text file to go with this test would then look like:

Type, Number, Expected, [ExpectedException]
Home, (732) 555-1012 begin_of_the_skype_highlighting              (732) 555-1012      end_of_the_skype_highlighting, 7325551012
Home, , , ArgumentException

There are a few things to note here:

1. If no exceptions are associated with the row, don't include a trailing comma and empty value (see the first line).
2. The headers are not case sensitive.
3. Null values can be specified using an empty value.
4. When specifying exceptions, you do not need to use typeof(ArgumentException), just the type is enough.

Happy (unit) testing!