Posts Tagged C#

Fun with C#: Create fluent assertions for your domain

When writing tests, we should strive to make the test code just as good (if not better) as the production code. Embedding your domain’s language into your test assertions can help a lot with that.

Take the following example:

[TestMethod]
public void MeatLover()
{
    var pizzaMaker = new PizzaMaker();

    var meatLoverPizza = pizzaMaker.MakeMeatLover();

    Assert.IsTrue(meatLoverPizza.Toppings.Any(topping => topping.Name == "Pepperoni"));
    Assert.IsTrue(meatLoverPizza.Toppings.Any(topping => topping.Name == "Italian sausage"));
    Assert.IsTrue(meatLoverPizza.Toppings.Any(topping => topping.Name == "bacon"));
    Assert.IsTrue(meatLoverPizza.Toppings.Any(topping => topping.Name == "ham"));
    Assert.IsTrue(meatLoverPizza.Toppings.Any(topping => topping.Name == "mozzarella"));
}

Our PizzaMaker class is supposed to make meat lover pizzas, so whenever it does, it’s expected to have a specific list of toppings on it. The test above captures that requirement. However, the assertions are very noisy. I’d like to have my test read like so instead:

[TestMethod]
public void MeatLover()
{
    var pizzaMaker = new PizzaMaker();

    var meatLoverPizza = pizzaMaker.MakeMeatLover();

    meatLoverPizza.ShouldHaveToppings("Pepperoni", "Italian sausage", "bacon", "ham", "mozzarella");
}

Notice that code in the test no longer has things like calls to Assert, or Any, or lambdas. It only has the bare minimum required by the C# compiler, and it is a lot easier to read so we understand the actual requirement being verified. Writing the tests that way allows me to collaborate with other developers, QA, and Business Analysts, as they can follow the code a lot more easily.

So, where does the ShouldHaveToppings method for the Pizza class comes from? A simple Extension Method:

public static class PizzaAssertionExtensions 
{
    public static void ShouldHaveToppings(this Pizza pizza, params string[] toppingNames)
    {
        foreach (var toppingName in toppingNames)
        {
            Assert.IsTrue(pizza.Toppings.Any(topping => topping.Name == toppingName),
                "Topping missing: " + toppingName);
        }
    }
}

To make things even better, I’d like my code to read like this:

meatLoverPizza.Should().HaveToppings("Pepperoni", "Italian sausage", "bacon", "ham", "mozzarella");

That way, my extension method would simply be called HaveToppings. In order to implement it that way, I’d look into making my fluent assertions extend FluentAssertions.

In summary, instead of just using plain calls to Assert, create fluent assertions that map to the nouns and verbs that exist in your domain.

2 Comments

Fun with C#: Create a handy calendar using Iterators

Here’s something fun with can do with C#. Imagine we need to work with dates within a given year. For instance, I want to list out all days within the year of 2017. A little Calendar class like the one below would be handy:

var calendar = new Calendar(2017);
var days = calendar;
foreach (var day in days)
{
    Console.WriteLine(day);
}

The output looks somewhat like this:

What if I wanted to list all days in january, like so:

var days = calendar. Where(d => d.Month == 1);

The output:

Last but not least, maybe I want to list all Saturdays in january:

var days = calendar.Where(d => d.Month == 1 && d.DayOfWeek == DayOfWeek.Saturday))

The output:

One could think that under the hood the Calendar class uses some sort of Collection, Array or List of DateTime objects. In reality, it uses an iterator, implemented using the yield return keywords:

public class Calendar : IEnumerable<DateTime>
{
readonly int _year;

public Calendar(int year)
{
_year = year;
}

public IEnumerator<DateTime> GetEnumerator()
{
var firstDayOfTheYear = new DateTime(_year, 1, 1);
var lastDayOfTheYear = new DateTime(_year, 12, 31);
var daysInTheYear = (lastDayOfTheYear - firstDayOfTheYear).TotalDays;

for (int i = 0; i <= daysInTheYear; i++)
{
yield return firstDayOfTheYear.AddDays(i);
}
}

IEnumerator IEnumerable.GetEnumerator()
{
return GetEnumerator();
}
}

Ain’t that fun and handy? 🙂

I really like this combination of IEnumerable<T>, iterators, and LINQ.

Leave a comment

Fun with C#: Using delegates to get rid of switch-blocks

I’m starting a new series here: Fun with C#! The idea is to post a couple of things I do in this cool language. 🙂

When I talk about Clean Code with developers, an example that I always use is switch-blocks. Every bad code out there always features abusive use of switch-blocks. In most cases, those blocks start off very simple, with one-liners, like the sample below:

public void DoStuff(DayOfTheWeek dayOfTheWeek)
{
    switch (dayOfTheWeek)
    {
        case DayOfTheWeek.Sunday:
            Console.WriteLine("Do stuff for Sunday...");
            break;
        case DayOfTheWeek.Monday:
            Console.WriteLine("Do stuff for Monday...");
            break;
        case DayOfTheWeek.Tuesday:
            Console.WriteLine("Do stuff for Tuesday...");
            break;
        case DayOfTheWeek.Wednesday:
            Console.WriteLine("Do stuff for Wednesday...");
            break;
        case DayOfTheWeek.Thursday:
            Console.WriteLine("Do stuff for Thursday...");
            break;
        case DayOfTheWeek.Friday:
            Console.WriteLine("Do stuff for Friday...");
            break;
        case DayOfTheWeek.Saturday:
            Console.WriteLine("Do stuff for Saturday...");
            break;
    }
}

It always start off simple like that. Next thing you know, there’s another “simple change” that comes in, and now the code looks somewhat like this:

public void DoStuff(DayOfTheWeek dayOfTheWeek, TimeOfTheDay timeOfTheDay)
{
    switch (dayOfTheWeek)
    {
        case DayOfTheWeek.Sunday:
            Console.WriteLine("Do stuff for Sunday...");
            if (timeOfTheDay == TimeOfTheDay.Evening)
            {
                Console.WriteLine("Go to bed early!");
            }
            break;
		...
        case DayOfTheWeek.Saturday:
            if (timeOfTheDay == TimeOfTheDay.Morning)
            {
                Console.WriteLine("You may stay a little longer in bed...");
            }
            else
            {
                Console.WriteLine("Do stuff for Saturday...");
            }
            break;
    }
}

Then comes an if-else, a for-loop, a switch-block (yes, inside the other switch, of course), and that one method becomes a terrible mess.

Well, whenever I see a case like that, I consider changing the switch-block into a dictionary of actions. I populate a dictionary with the individual blocks of code I need executed, and then I get the delegate out of the dictionary and invoke it whenever needed. The updated code would look like this:

readonly Dictionary<DayOfTheWeek, Action<TimeOfTheDay>> _dailyActions =
new Dictionary<DayOfTheWeek, Action<TimeOfTheDay>>();

public FamousSwitch()
{
_dailyActions.Add(DayOfTheWeek.Sunday, DoSunday());
_dailyActions.Add(DayOfTheWeek.Monday, DoMonday());
_dailyActions.Add(DayOfTheWeek.Tuesday, DoTuesday());
_dailyActions.Add(DayOfTheWeek.Wednesday, DoWednesday());
_dailyActions.Add(DayOfTheWeek.Thursday, DoThursday());
_dailyActions.Add(DayOfTheWeek.Friday, DoFriday());
_dailyActions.Add(DayOfTheWeek.Saturday, DoSaturday());
}

Action<TimeOfTheDay> DoSaturday()
{
return timeOfTheDay =>
{
if (timeOfTheDay == TimeOfTheDay.Morning)
{
Console.WriteLine("You may stay a little longer in bed...");
}
else
{
Console.WriteLine("Do stuff for Saturday...");
}
};
}

Action<TimeOfTheDay> DoFriday()
{
return timeOfTheDay => Console.WriteLine("Do stuff for Friday...");
}

Action<TimeOfTheDay> DoThursday()
{
return timeOfTheDay => Console.WriteLine("Do stuff for Thursday...");
}

Action<TimeOfTheDay> DoWednesday()
{
return timeOfTheDay => Console.WriteLine("Do stuff for Wednesday...");
}

Action<TimeOfTheDay> DoTuesday()
{
return timeOfTheDay => Console.WriteLine("Do stuff for Tuesday...");
}

Action<TimeOfTheDay> DoMonday()
{
return timeOfTheDay => Console.WriteLine("Do stuff for Monday...");
}

Action<TimeOfTheDay> DoSunday()
{
return timeOfTheDay =>
{
Console.WriteLine("Do stuff for Sunday...");
if (timeOfTheDay == TimeOfTheDay.Evening)
{
Console.WriteLine("Go to bed early!");
}
};
}

public void DoStuff(DayOfTheWeek dayOfTheWeek)
{
_dailyActions[dayOfTheWeek].Invoke(TimeOfTheDay.Morning);
}

I like keeping the smaller individual methods for each operation. Most often than not, I’ll end up moving those separate methods into one separate class, and very often, will turn that one separate class into several separate classes.

Anyway…

  • I like using a dictionary of delegates instead of using switch-blocks;
  • I like having small methods a lot better than having one long method

Leave a comment

How to do XML comparison in an application?

Working on a tool that does some end-to-end testing, I have a need to compare xml input/output. Comparing xml isn’t a simple string comparison, as a single extra space would deem the results aren’t equal. I need to compare both the structure as well as the actual data contained in the xml.

This is a .NET application. I’ve looked for some components out there that perform such comparison and found some, but there’s still quite a bit of work involved in taking the results the components give me (listing each line and each difference) and showing it to the user in a meaningful way.

Instead of spending a lot of time (and therefore, a lot of my client’s money), I figured the easiest/cheapest way to implement this was to simply integrate Beyond Compare into the app. That way, it’s very, very easy to see what the differences are between the two xml documents, as Beyond Compare clearly shows the differences down to the attribute level.

The way I’m doing it is my saving the XML content to disk, and then firing up Beyond Compare using the Process class, passing along the path to the files. (see code below)

public class XmlDiffController : IXmlDiffController    
{        
	public void OpenDiff(string leftXml, string rightXml)        
	{            
		var leftResultsXml = @"c:\temp\left-results.xml";
    	File.WriteAllText(leftResultsXml, leftXml);
    	var rightesultsXml = @"c:\temp\right-results.xml";
    	File.WriteAllText(rightesultsXml, rightXml);    
        
		Process.Start(new ProcessStartInfo(TesterSettings.DiffToolPath)
		{                
			WindowStyle = ProcessWindowStyle.Maximized,                
			Arguments = string.Format("\"{0}\" \"\"", 
								 leftResultsXml, rightResultsXml)            
		});
 	 }  
}

 

DiffToolPath is the path to Beyond Compare on my environment. As I’m doing this development on a Windows Virtual Machine inside a Mac host, my DiffToolPath points to Beyond Compare on my Mac, like I’ve described on my Integration of Beyond Compare and Parallels on the Mac post.

Works like a charm, quick, cheap, and easy!

Leave a comment

Fun with Extension Methods and Enums

Extension methods are one of my favorite features in C# 3.0. Tim Rayburn has already posted something about how we can use extension methods on interfaces to do some cool things, allowing us to sort of provide some implementation code to interfaces.

Yesterday I was implementing something in a project that involved an enum, and was wandering whether extension methods also apply to enums; and they do!

Here’s the scenario: I have a ComparisonOperator enum that I use to keep a list of comparison operators that may be used to create where clauses on the fly. This enum looks something like this:

    public enum ComparisonOperator
    {
        Like,
        Equals,
        NotEquals,
        LessThan,
        GreaterThan
    }

In places where I use this enum, I need to convert values to their SQL equivalent. For instance, Equals should translate to "=", LessThan should translate to "<", and so on.

In .NET 2.0 I have created a helper method somewhere with a switch statement that does the translation, since enums cannot have their own methods. In .NET 3.5, though, I can create an extension method like so:

    public static class EnumExtensions
    {
        public static string ToSql(this ComparisonOperator token)
        {
            string sqlEquivalent = String.Empty;
            switch (token)
            {
                case ComparisonOperator.Like:
                    sqlEquivalent = "LIKE";
                    break;
                case ComparisonOperator.Equals:
                    sqlEquivalent = "=";
                    break;
                case ComparisonOperator.NotEquals:
                    sqlEquivalent = "!=";
                    break;
                case ComparisonOperator.LessThan:
                    sqlEquivalent = "<";
                    break;
                case ComparisonOperator.GreaterThan:
                    sqlEquivalent = ">";
                    break;
            }
            return sqlEquivalent;
        }
    }

The ToSql method extends the ComparisonOperator enum, by providing the translation between the enum value and the SQL equivalent string. Now I can easily use my enum and call the extension method on it, like so:

            ComparisonOperator likeOperator = ComparisonOperator.Like;
            ComparisonOperator notEqualsOperator = ComparisonOperator.NotEquals;
            ComparisonOperator lessThanOperator = ComparisonOperator.LessThan;

            Console.WriteLine(likeOperator.ToSql());  // prints LIKE
            Console.WriteLine(notEqualsOperator.ToSql()); // prints !=
            Console.WriteLine(lessThanOperator.ToSql()); // prints <

Of course, this is something that not every developer would understand, because nobody expects an enum to have methods, but things like this will begin to show up as people get more used to the new features in .NET 3.5.

Leave a comment

C#3.0 WebCast for the VBUG – Material

Just finished the presentation. It went pretty well, I think (or so was I told).  🙂

The slide deck and source code can be download here.

And for those of you waiting on my next posts on productivity, it is coming! I started writing my next post, but haven’t finished yet. I should have it out on the next few days.

Leave a comment