Mark Gilbert's Blog

Science and technology, served light and fluffy.

Will you just wait a minute?! NUnit and Async/Await

I was being a good-doobie.  Honest.

I had written a prototype – just something to prove that a particular approach could work.  It did, and so now it was time for me to actually bring that code up to production quality.  Part of that meant modifying how I was invoking the third-party web services – they  needed to be done asynchronously.

So I went through and wrote my unit tests to also run asynchronously:

        [Test]
        public async void Divide_4DividedBy2_Equals2()
        {
            AsyncUnitTest.Math MathLibrary = new AsyncUnitTest.Math();

            float Quotient = await MathLibrary.Divide(4, 2);

            Assert.AreEqual(2, (int)Quotient);
        }

I ran it through NUnit on my machine, and everything was peachy-keen.  I ended up writing nearly 50 unit tests* like that, converting over all of my calls.  I committed the code, and let TeamCity take over.

And watched every one of those new tests break.

When I looked at the TeamCity log, the errors seemed to hint that the test runner was simply not waiting for the thing under test to complete before trying to run the asserts.  I started searching for things like "nunit async", and pretty quickly across this two-part series by Stephen Cleary:

In this series, Cleary says that the underlying problem of running async tests is that they don’t have a proper context:

We’ve encountered a situation very similar to async in Console programs: there is no async context provided for unit tests, so they’re just using the thread pool context. This means that when we await our method under test, then our async test method returns to its caller (the unit test framework), and the remainder of the async test method – including the Assert – is scheduled to run on the thread pool. When the unit test framework sees the test method return (without an exception), then it marks the method as “Passed”. Eventually, the Assert will fail on the thread pool.

His solution is to simply give the test an async context, and he provides a very handy wrapper to do just that.  I first had to install his Nito.AsyncEx NuGet package, and then wrap my test in AsyncContext.Run:

        [Test]
        public void Divide_4DividedBy2_Equals2_Asynchrofied()
        {
            AsyncContext.Run(async () =>
            {
                AsyncUnitTest.Math MathLibrary = new AsyncUnitTest.Math();

                float Quotient = await MathLibrary.Divide(4, 2);

                Assert.AreEqual(2, (int)Quotient);
            });
        }

Notice that I’ve removed the "async" keyword from the test itself; AsyncContext.Run does all the work here.  After updating and committing my first test using AsyncContext.Run – a test test, if you will – it ran successfully on TeamCity.  I updated the other 48, and finally got a green build.

***

My build was stable again, but Cleary’s explanation didn’t answer the question of why this worked on my machine in the first place – without using his very awesome library – so, I kept digging.

I first looked up exactly what TeamCity was using to run the tests – it was NUnit, the same as what was on my machine, with a minor different in the version.  My local copy was 2.6.2, while the version on the build server was 2.6.1.  Could there be a difference in how 2.6.1 was handling async?

Why yes.  Yes there was.  In the NUnit 2.6.2 release notes I found this:

When running under .NET 4.5, async test methods are now supported. For test cases returning a value, the method must return Task<T>, where T is the type of the returned value. For single tests and test cases not returning a value, the method may return either void or Task.

- Source: http://nunit.org/index.php?p=releaseNotes&r=2.6.2

Are you serious?  I just happen to have the first version of NUnit that would properly handle async on my machine, but the build server was one notch older, and therefore couldn’t?  *facepalm*

To further prove that this was the real source of my issue, I installed NUnit 2.6.1 and 2.6.2 side by side on my machine.  I took my two tests from above, both of which should have tried to execute the MathLibrary.Divide function which included a 2-second delay:

    public class Math
    {
        public async Task<float> Divide(int Numerator, int Denominator)
        {
            await Task.Delay(2000);
            return Numerator / Denominator;
        }
    }

When I ran these two tests through NUnit 2.6.1, Divide_4DividedBy2_Equals2 completes in a couple hundredths of a second, while Divide_4DividedBy2_Equals2_Asynchrofied takes just over 2 seconds to complete, for a total of just over 2 seconds:

2-6-1

When I ran these through NUnit 2.6.2, EACH test takes just over 2 seconds to complete, for a total of just over 4 seconds:

2-6-2

So, I have two choices – switch my builds on TeamCity to use at least NUnit 2.6.2 to run the tests, or use Cleary’s Nito.AsyncEx library, which will allow me to leave the build server as is.  In any event, at least I have a reasonable explanation for what was happening. 

The funny thing is that it’s usually MSBuild that messes with me.  Apparently NUnit gave him the week off.

 


* Yes, I realize that by calling the service directly, this no longer counts as a "unit" test, but rather an integration test.  That distinction isn’t relevant to the issue described in this post, though, so I’m going to gloss over the mock objects in the real code.

October 23, 2014 Posted by | Agile, Visual Studio/.NET | Comments Off

Balloon Mapper

Our receiving station for the Stratoballoon project consisted of three major pieces of software:

I’ve gone into great depth about how the first two are configured on my technical blog (“Stratoballoon Radio Details”).  Today, I want to talk about the third one, BalloonMapper.  Here is the basic interface:

10

We would copy a dataline out of dl-fldigi and past it into the "Data Line" box (#1).  We could then hit Enter, or manually click the "Find Position" button in the upper right corner.  This would extract the altitude, and the lat/long from the data string.  It would convert the former into feet and display that in the "Altitude" box (#2).  It would also create the Google Maps URL that would show the lat/long as a pin on the map.

What did the data strings look like?  A picture-perfect data string that came off the radio would look like this:

    KD8VZA-KD8VZA-KD8VZA,120057.00,234.11,4214.7460,8533.3750,*4FF4

This is a comma-delimited string, and is made up of the following:

  • My callsign, repeated 3 times
  • A timestamp, in hhmmss.xx format (where the decimal places are ignored)
  • The altitude, in meters
  • The latitude (format explained below)
  • The longitude (format explained below)
  • A termination string, made up of an asterisk, followed by four alphanumeric characters

In most cases the callsigns came out a bit garbled, so it would look more like this:

    a8czZA-KD8VZA-KD8VZA,120057.00,234.11,4214.7460,8533.3750,*4FF4

The first part of the string got chewed up because it took us a second to tune dl-fldigi to lock onto the signal.  That’s the main reason I start the string with three copies – I wanted to give Katherine or I (whoever was working the radio) a second or two to get ahold of the signal.

Extracting the altitude was very straightforward.  Simply grab the 3rd piece of data in the string, multiple it by 3.28 to convert it from meters to feet, and display it in the box.

        public static String GetAltitude(String DataLine)
        {
            String[] DataLineComponents;
            String RawAltitude;

            DataLine = (DataLine ?? "").Trim();
            if (String.IsNullOrEmpty(DataLine)) { return ""; }

            DataLineComponents = DataLine.Split(',');

            RawAltitude = DataLineComponents[2];

            return String.Format("{0} ft", (double.Parse(RawAltitude) * 3.28).ToString("0"));
        }

The lat/long was a bit tricker.  First, I had to get them into a format that Google Maps would understand.  You can browse directly to a specific lat/long point on Google Maps like so:

    https://www.google.com/maps/place/42°17’44.76"N+85°43’22.50"W

The lat/long values, however, always come off the radio in the 4-dot-4 pattern.  Here is how they broke down:

    4214.7460 = 42° 14.7460′

    8533.3750 = 85° 33.3750′

So, I would need to split the degrees from the rest of the string, then convert the fractional arc-minutes into arc-seconds, before I could drop it into Google Maps:

        public static String GetUrl(String DataLine)
        {
            String[] DataLineComponents;
            String RawLat, RawLong, FormattedLat, FormattedLong;

            DataLine = (DataLine ?? "").Trim();
            if (String.IsNullOrEmpty(DataLine)) { return ""; }

            DataLineComponents = DataLine.Split(',');

            RawLat = DataLineComponents[3];
            RawLong = DataLineComponents[4];

            FormattedLat = String.Format("{0}°{1}'{2}\"", RawLat.Substring(0, 2),
                                                          RawLat.Substring(2, 2),
                                                          (double.Parse(RawLat.Substring(4)) * 60).ToString("00.00"));
            FormattedLong = String.Format("{0}°{1}'{2}\"", RawLong.Substring(0, 2),
                                                           RawLong.Substring(2, 2),
                                                           (double.Parse(RawLong.Substring(4)) * 60).ToString("00.00"));

            return String.Format("https://www.google.com/maps/place/{0}N+{1}W", FormattedLat, FormattedLong);
        }

So, now I had my URL.  I needed a way to embed a browser into BalloonMapper, which was a Windows desktop app.  I looked at a few options, but eventually settled on Gecko Effects: https://bitbucket.org/geckofx/geckofx-29.0/downloads.

I created a Gecko.GeckoWebBrowser object on my form called "GoogleMaps".  To browse to a URL, I simply called the .Navigate() method on the GoogleMaps object, and passed it the URL that I generated above:

                this.GoogleMaps.Navigate(GetUrl(this.DataLineBox.Text));

 

Using it was easy.  Getting the control installed and working was a little more difficult, and I had a few false starts.  In the end, here is what worked:

  • I downloaded Gecko Effects 29.0 (see link above).
  • Gecko requires another application called "xulrunner", which I obtained from here: http://ftp.mozilla.org/pub/mozilla.org/xulrunner/releases/29.0.1/runtimes/
  • I found that I needed to match the version of xulrunner to the version of Gecko, otherwise I got a "Specified cast is not valid" error.
  • I also found that the program has to be installed to a folder called "xulrunner" – all lowercase – or it wouldn’t work.

This made finding the capsule’s current location extremely easy:

20

For full source code and binaries, please visit http://TinyURL.com/MarkGilbertSource, and look for the BalloonMapper.zip archive.

October 10, 2014 Posted by | Science, Visual Studio/.NET | 1 Comment

Resisting the woodpeckers – Builder Pattern

If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.
– (Gerald) Weinberg’s Second Law

A couple of months ago, I found a recommendation on my company’s intranet for "Growing Object-Oriented Software, Guided by Tests" by Steve Freeman and Nat Pryce.  I am an avid reader, but believe or not, I haven’t actually managed to read all the books yet, so I checked this one out from the library, and went through it. 

One of the real gems I found inside was a pattern I hadn’t seen before – the builder pattern (for those of you who have the book, this appears starting on page 258).  The goal here is to create data for a test in a way that keeps your test clean, but also gives you the flexibility to change that data when you need to.  It is also very expressive – you know exactly what part of the data is being changed just by reading the setup code.

Their example, which is what sold me on this pattern looks like this:

new AddressBuilder()
       .build();

This would get you a simple address, with (presumably) default, valid, values.  Next, the builder class would allow you to modify the defaults using methods like so:

new AddressBuilder()
       .withStreet("221b Baker Street")
       .withStreet2("London")
       .withPostCode("NW1 6XE")
       .build();

The methods withStreet(), withStreet2(), and withPostCode() would override the address 1, address 2, and postal code, respectively.  What’s more, this is far clearer than writing a method like UpdateTestData("221b Baker Street", “London”, "NW1 6XE") to do the same thing – is the second parameter modifying the street address or the city?  You no longer know at a glance, you now have to dig into the code to find out.

I’ve had to do things like this in the past numerous times, and my setup code for this has been wearisome-at-best to maintain.  Not only is this pattern clean and expressive, but it could start out simple and grow with my tests.  I could start out with the default case, and if I found that I later needed to test a case involving a custom postal code, I could add a method that allowed me to inject that value.  I wouldn’t have to touch any of my other tests, or do anything crazy with my setup logic – I would just have to add a method, and chain it for the one test that needed it.

I vowed that my next project would use this pattern, and in the last couple of weeks, I got the opportunity to put it to good use.  I was building a mechanism for NLog that would allow me to configure it from a database (rather than from web.config/app.config; I won’t go into detail on how this is done, but it turns out to be rather straightforward: https://github.com/nlog/NLog/wiki/Configuration-API ).  I would pass in a Dictionary of name-value pairs for the properties, and then I wanted to test that the proper NLog target and logger was configured (out of the gate I wanted to support a database target and a mail target).

After some back and forth – some of which was me getting comfortable with the pattern, and some of which was me letting the tests drive the functionality that I needed – I arrived at the following structure:

private class NLogSettingsBuilder
{
    private List<KeyValuePair<String, String>> _Settings;

    public NLogSettingsBuilder()
    {
        this._Settings = new List<KeyValuePair<String, String>>();
    }

    public NLogSettingsBuilder WithAllDatabaseSettings()
    {
        this._Settings = new List<KeyValuePair<String, String>>();
        this._Settings.Add(new KeyValuePair<String, String>("Target.Database.connectionStringName", "SomeName"));
        this._Settings.Add(new KeyValuePair<String, String>("Target.Database.commandText", "insert into EventLog ([Origin], [LogLevel], [Message], [StackTrace], SourceMachine) values (@origin, @logLevel, @message, @stackTrace, @sourceMachine);"));
        this._Settings.Add(new KeyValuePair<String, String>("Target.Database.name", "database"));
        this._Settings.Add(new KeyValuePair<String, String>("Target.Database.Parameter.origin", "Services"));
        this._Settings.Add(new KeyValuePair<String, String>("Target.Database.Parameter.logLevel", "${level:uppercase=true}"));
        this._Settings.Add(new KeyValuePair<String, String>("Target.Database.Parameter.message", "${message}"));
        this._Settings.Add(new KeyValuePair<String, String>("Target.Database.Parameter.stackTrace", "${stacktrace}"));
        this._Settings.Add(new KeyValuePair<String, String>("Target.Database.Parameter.sourceMachine", "${machinename}"));

        this._Settings.Add(new KeyValuePair<String, String>("Logger.Database.minlevel", "Error"));
        return this;
    }

    public NLogSettingsBuilder WithAllMailSettings()
    {
        this._Settings = new List<KeyValuePair<String, String>>();
        this._Settings.Add(new KeyValuePair<String, String>("Target.Mail.name", "email"));
        this._Settings.Add(new KeyValuePair<String, String>("Target.Mail.subject", "Blah Local Dev Error"));
        this._Settings.Add(new KeyValuePair<String, String>("Target.Mail.to", "mgilbert@blah.com"));
        this._Settings.Add(new KeyValuePair<String, String>("Target.Mail.from", "nlog@blah.com"));
        this._Settings.Add(new KeyValuePair<String, String>("Target.Mail.smtpServer", "smtp.blah.com"));
        this._Settings.Add(new KeyValuePair<String, String>("Target.Mail.encoding", "UTF-8"));
        this._Settings.Add(new KeyValuePair<String, String>("Target.Mail.body", "Timestamp: ${longdate}${newline}Level: ${level:uppercase=true}${newline}Logger: ${logger}${newline}Machine Name: ${machinename}${newline}${newline}Message: ${message}${newline}${newline}Stacktrace: ${stacktrace}"));
        this._Settings.Add(new KeyValuePair<String, String>("Target.Mail.html", "true"));

        this._Settings.Add(new KeyValuePair<String, String>("Logger.Mail.minlevel", "Error"));
        return this;
    }

    public NLogSettingsBuilder WithoutSetting(String Key)
    {
        this._Settings.RemoveAll(setting => setting.Key == Key);
        return this;
    }

    public NLogSettingsBuilder WithThisSettingAltered(String Key, String NewValue)
    {
        this.WithoutSetting(Key);
        this._Settings.Add(new KeyValuePair<String, String>(Key, NewValue));
        return this;
    }

    public Dictionary<String, String> Build()
    {
        Dictionary<String, String> NewSettings = new Dictionary<String, String>();
        if (this._Settings != null)
        {
            foreach (KeyValuePair<String, String> CurrentPair in this._Settings) { NewSettings.Add(CurrentPair.Key, CurrentPair.Value); }
        }
        return NewSettings;
    }
}

That allowed me to test things like:

this._NLogSettings = (new NLogSettingsBuilder())

                               .Build();

The default case, where there are no properties configured, and therefore no NLog targets will be configured.

this._NLogSettings = (new NLogSettingsBuilder())

                               .WithAllDatabaseSettings()

                               .Build();

All of the correct database settings will be present, so I should expect the database target and logger to be configured.

this._NLogSettings = (new NLogSettingsBuilder())

                               .WithAllMailSettings()

                               .Build();

All of the correct mail settings will be present, so I should expect the mail target and logger to be configured.

this._NLogSettings = (new NLogSettingsBuilder())

                               .WithAllDatabaseSettings()

                               .WithoutSetting("Target.Database.connectionStringName")

                               .Build();

All of the correct database settings will be present except for "Target.Database.connectionStringName".  Since this is a required property, I should not expect the database target and logger to be configured.

this._NLogSettings = (new NLogSettingsBuilder())

                               .WithAllDatabaseSettings()

                               .WithThisSettingAltered("Target.Database.connectionStringName", "Blah")

                               .Build();

All of the correct database settings will be present, and "Target.Database.connectionStringName" will have the value of "Blah".  I should not expect the database target and logger to be configured, and I should be able to test the connectionStringName property and confirm that its value matches "Blah".

As I said before, as soon as I read this, I was hooked.  I’ve struggled in the past to keep my test data manageable, and have had to bit a lot of bullets to make sweeping changes to keep it up to date.  This kind of pattern will help that immensely, and will go a great way, I think, to keeping the digital woodpeckers at bay.

April 23, 2014 Posted by | Visual Studio/.NET | Comments Off

Reducing the Tedium: Redux

Back in July, I wrote “Reducing the Tedium: Generalized Unit Tests via Reflection” which introduced a generalized unit test for strings and IDs in a pre-defined list of classes.  This was my first stab at trying to automate some of the more tedious tests I typically write for properties of this sort.  With my latest project, I was able to extend this even further with a new “PropertyValidator” class.

My first task was to eliminate the need for the explicit “TypesToCheck” array that defined which classes to test.  Since a lot of my use cases was checking business classes in the same assembly, I started by building a method that could take the name of the assembly to test as a parameter, open that assembly up via Reflection, and find all of the classes in it.

I started by repackaging my original code into two main functions – one for validating strings:

private static void ValidateStrings(Type CurrentType)
{
    String TestValue, ClassName;
    PropertyInfo[] ClassProperties;
    Object ClassInstance;
    
    ClassName = CurrentType.Name;
    ClassProperties = CurrentType.GetProperties().Where(p => p.PropertyType == typeof(String) && p.GetSetMethod() != null).ToArray();
    ClassInstance = Activator.CreateInstance(CurrentType);

    foreach (var PropertyUnderTest in ClassProperties)
    {
        if (ShouldSkipProperty(PropertyUnderTest)) { continue; }

        TestValue = (String)PropertyUnderTest.GetValue(ClassInstance, null);
        Assert.IsEmpty(TestValue, String.Format("{0}.{1} did not initialize properly", ClassName, PropertyUnderTest.Name));

        PropertyUnderTest.SetValue(ClassInstance, null, null);
        TestValue = (String)PropertyUnderTest.GetValue(ClassInstance, null);
        Assert.IsEmpty(TestValue, String.Format("{0}.{1} did not handle null properly", ClassName, PropertyUnderTest.Name));

        PropertyUnderTest.SetValue(ClassInstance, "", null);
        TestValue = (String)PropertyUnderTest.GetValue(ClassInstance, null);
        Assert.IsEmpty(TestValue, String.Format("{0}.{1} did not handle an empty string properly", ClassName, PropertyUnderTest.Name));

        PropertyUnderTest.SetValue(ClassInstance, "  ", null);
        TestValue = (String)PropertyUnderTest.GetValue(ClassInstance, null);
        Assert.IsEmpty(TestValue, String.Format("{0}.{1} did not handle a blank string properly", ClassName, PropertyUnderTest.Name));

        PropertyUnderTest.SetValue(ClassInstance, "abc123", null);
        TestValue = (String)PropertyUnderTest.GetValue(ClassInstance, null);
        Assert.AreEqual("abc123", TestValue, String.Format("{0}.{1} did not handle a valid string properly", ClassName, PropertyUnderTest.Name));
    }
}

 

And the other for validating IDs:

private static void ValidateIDs(Type CurrentType)
{
    long TestValue;
    String ClassName;
    PropertyInfo[] ClassProperties;
    Object ClassInstance;

    ClassName = CurrentType.Name;
    ClassProperties = CurrentType.GetProperties();
    ClassInstance = Activator.CreateInstance(CurrentType);

    foreach (var PropertyUnderTest in ClassProperties.Where(p => IsIDToValidate(p)))
    {
        if (PropertyUnderTest.GetCustomAttributes(typeof(ObsoleteAttribute), true).Count() > 0) { continue; }

        TestValue = (long)PropertyUnderTest.GetValue(ClassInstance, null);
        Assert.AreEqual(0, TestValue, String.Format("{0}.{1} did not initialize properly", ClassName, PropertyUnderTest.Name));

        PropertyUnderTest.SetValue(ClassInstance, 0, null);
        TestValue = (long)PropertyUnderTest.GetValue(ClassInstance, null);
        Assert.AreEqual(0, TestValue, String.Format("{0}.{1} did not handle being set to 0 properly", ClassName, PropertyUnderTest.Name));

        PropertyUnderTest.SetValue(ClassInstance, -1, null);
        TestValue = (long)PropertyUnderTest.GetValue(ClassInstance, null);
        Assert.AreEqual(0, TestValue, String.Format("{0}.{1} did not handle being set to a negative properly", ClassName, PropertyUnderTest.Name));
    }
}

 

These do the same basic checks on each string or ID property as described in the July post.  They make use of three helper functions – ShouldSkipType, ShouldSkipProperty, and IsIDToValidate.  I’ll describe these in turn:

private static bool ShouldSkipType(Type CurrentType)
{
    return CurrentType.GetCustomAttributes(typeof(PropertyValidator.Attributes.DoNotPerformBasicValidation), true).Length > 0 
        || CurrentType.IsGenericType 
        || CurrentType.IsAbstract
        || CurrentType.FullName.StartsWith("PostSharp");
}

The ShouldSkipType function returns True if the class:

  • is a generic type
  • is an abstract type
  • starts with “PostSharp” (this is a logging library that I started using this summer, and its classes are added to mine post-build; trying to run my test code against these classes cause problems, so I just skip them entirely)
  • has the custom “DoNotPerformBasicValidation” attribute attached.

If any of these conditions is met, the class is skipped.  I found a need to create exceptions to the rule of “check every class in this assembly”, so I created the “DoNotPerformBasicValidation” attribute that I could decorate a specific class in an assembly to be skipped.  This attribute has no logic of its own – it is merely used as a flag on the class:

using System;
using System.Collections.Generic;
using System.Linq;

namespace PropertyValidator.Attributes
{
    [AttributeUsage(AttributeTargets.All)]
    public class DoNotPerformBasicValidation : Attribute 
    { 
    }
}

This attribute can be applied to not only classes, but also individual properties, and the ShouldSkipProperty function looks for that:

private static bool ShouldSkipProperty(PropertyInfo CurrentProperty)
{
    return CurrentProperty.GetCustomAttributes(typeof(PropertyValidator.Attributes.DoNotPerformBasicValidation), true).Length > 0;
}

This function returns True if the custom attribute is found on the current property being evaluated.

Finally, to determine if a given property is a string, “ValidateStrings” merely looks at the property’s type.  To determine if it is an ID to be checked is a little trickier.  I can’t rely solely on its base type, so instead I require that property to be treated as an ID is marked as such, with another custom attribute:

using System;
using System.Collections.Generic;
using System.Linq;

namespace PropertyValidator.Attributes
{
    [AttributeUsage(AttributeTargets.Property)]
    public class ValidateAsID : Attribute 
    {
    }
}

When the “ValidateAsID” attribute is applied to a property, the “IsIDToValidate” function returns true:

private static bool IsIDToValidate(PropertyInfo CurrentProperty)
{
    return CurrentProperty.GetCustomAttributes(typeof(PropertyValidator.Attributes.ValidateAsID), true).Length > 0;
}

 

The “ValidateStrings” and “ValidateIDs” functions need a list of classes to open and examine.  That list is provided by the PropertyValidator’s “Validate” methods:

public static void Validate(String AssemblyPartialName)
{
    Validate(AssemblyPartialName, null);
}
public static void Validate(String AssemblyPartialName, String ClassName)
{
    Assembly AssemblyToValidate;
    Type[] AssemblyTypes;

    AssemblyToValidate = Assembly.Load(AssemblyPartialName);
    if (AssemblyToValidate == null) { throw new Exception(String.Format("Could not load {0}", AssemblyPartialName)); }

    AssemblyTypes = AssemblyToValidate.GetTypes();

    foreach (Type CurrentType in AssemblyTypes)
    {
        try
        {
            if (ShouldSkipType(CurrentType)) { continue; }
            if (ClassName != null && CurrentType.Name != ClassName) { continue; }

            System.Diagnostics.Trace.WriteLine(String.Format("Now testing '{0}'", CurrentType.Name));

            ValidateStrings(CurrentType);
            ValidateIDs(CurrentType);
        }
        catch (Exception ex)
        {
            throw new Exception(String.Format("Error validating the type '{0}'", CurrentType.Name), ex);
        }
    }
}

The first takes only the assembly name, and will attempt to check every class in that assembly.   The second will allow you to check a single specific class in an assembly.  For each class being checked, then, the method will invoke both “ValidateStrings” and “ValidateIDs”.

To use it, then, I can do something as simple as

PropertyValidator.Validate(“MyAssembly”);

or

PropertyValidator.Validate(“MyAssembly”, “MyClass”);

***

PropertyValidator gives me a much better testing framework for properties than before, and is very easy to use.  I still have a dependency on NUnit, however, and it doesn’t do anything with other data types such as datetimes.  Perhaps the next iteration.

December 23, 2013 Posted by | Visual Studio/.NET | Comments Off

Now you see it, now you… still see it? Hiding Inherited Properties

A while ago, a colleague of mine, Doug, and I got into a conversation about inherited properties, and the potential for hiding them.  The precise scenario we were looking at was a base class with a "public” property, and a child class that descends from it with the same property redefined as "private".  We weren’t sure if we could do this at all, and even if we could, was it a good idea?  We ended up going a different way for the problem we were working on, but the conversation stuck in my head and I decided that I would look into it more when I had the chance.

Let’s start by defining a very simple base class:

    public class BaseClass
    {
        public String StringProperty { get; set; }
    }

And then define a child class to descend from it:

    public class ChildClass : BaseClass
    {
    }

Now, we’ll add a new version of "StringProperty", and let’s begin by keeping the scope the same:

    public class ChildClass : BaseClass
    {
        public new String StringProperty { get; set; }
    }

Next, let’s have ChildClass initialize "StringProperty" with a value:

    public class ChildClass : BaseClass
    {
        public new String StringProperty { get; set; }

        
        public ChildClass()
        {
            this.StringProperty = "INITIALIZED By Child";
        }
    }

Now, let’s write a small program that instantiates ChildClass, and reassigns "StringProperty":

    class Program
    {
        static void Main(string[] args)
        {
            ChildClass MyChildClass = new ChildClass();

            Console.WriteLine("Initialized:\t{0}", MyChildClass.StringProperty);
            MyChildClass.StringProperty = "ASSIGNED By Program";
            Console.WriteLine("Assigned:\t{0}", MyChildClass.StringProperty);

            Console.ReadLine();
        }
    }

As soon as I compile this, I’ll get a warning:

‘ParentChildProperties.ChildClass.StringProperty’ hides inherited member ‘ParentChildProperties.BaseClass.StringProperty’. Use the new keyword if hiding was intended.

(Let me point out a little grammatical issue here.  When I read this, my first question, “Ok, what’s the new keyword I’m supposed to use?”  What they meant was that the keyword to use is literally “new”.  That should have been enclosed in quotation marks in the above message.")

A little research turns up a couple of MSDN articles talking about this warning, and the larger topic of "hiding" inherited properties:

  1. http://msdn.microsoft.com/en-us/library/aa691135(v=vs.71).aspx
  2. http://msdn.microsoft.com/en-us/library/vstudio/435f1dw2.aspx

Adding the "new" modifier sounds like it only suppresses the warning, and doesn’t actually change the behavior of the properties, but let’s test that, too.

Scenario 1 – Same scopes, no "new" modifier

When I run the application built so far, I get the following output:

Scenario 1

The property is initialized and assigned as I would expect it.  Furthermore, when I inspect the initialized version of the property in the Visual Studio debugger, I see that ChildClass.StringProperty has the initialized value, but BaseClass’s version is null.  When I inspect the assigned value, ChildClass.StringProperty now has the assigned value, and the BaseClass version is still "null".

Scenario 2 – Scope is narrowed, no "new" modifier

If I change ChildClass.StringProperty to be "private", thus narrowing the scope of the property, this is the output:

Scenario 2

When I inspect the initialized value, the ChildClass and BaseClass properties are exactly the same as they were in Scenario 1, but this time the initialized value doesn’t get printed.  Once I assign a new value to it, that assigned value is printed out.  However, when I inspect StringProperty, I find that the ChildClass version still has the initialized value, but BaseClass’s version now has the assigned value.

Scenario 3 – Same scopes, added the "new" modifier

When I add the "new" modifier to ChildClass.StringProperty, and change the scope back to "public", I get the exact same results as Scenario 1.  This seems to confirm that the “new” modifier doesn’t change behavior – it only suppresses a warning.

Scenario 4 – Scope is narrowed, added the "new" modifier

When I changed the scope to "private" again, I get the exact same results as Scenario 3.  Again, this seems to confirm that the “new” modifier doesn’t change behavior.

 

So what’s going on here?  I believe this line from the first MSDN article explains it:

A declaration of a new member hides an inherited member only within the scope of the new member.

In this case, the new member’s scope is ChildClass.  When I declare "StringProperty" to be private, and then tried to access it from the program (now outside the scope of ChildClass), it couldn’t find that version, so it fell back to using on the base class version.  Since that version is never assigned, the program can only print out the "null". 

How do we explain what we were seeing through the debugger?  The debugger has always been able to inspect the full properties of a class – regardless of their scopes – so that’s why it can show me the assigned values properly every time.  However, assigning MyChildClass.StringProperty, then, must actually assign the base class version of this property, and it’s the base class version that is printed – not ChildClass’s version.

As the second article describes, this is really not so much "hiding" as it is "replacing".  That sends me back to the original question.  Is there a way to truly hide a base class property, so that it doesn’t even show up in Intellisense?

Jon Skeet responded to this exact question on a forum post on Bytes.com in 2006.  In short, no, this is not allowed:

…However, you can’t hide them in terms of preventing people from calling them. Doing so would violate Liskov’s Substitution Principle – you should always be able to treat a derived type as the base type.

***

So, the technique of hiding a property I think will be related to my "use sparingly" bucket.

Furthermore, while narrowing the property’s scope in the child class is allowed by the language, it

  1. makes things harder to troubleshoot
  2. will downright mislead me when I’m inspecting properties in the debugger
  3. seems unfit for any real-world scenario

QED – Narrowing scope is bad and should be avoided.

October 18, 2013 Posted by | Visual Studio/.NET | Comments Off

Breaking the Mold – Hacking together an Interface for Constants

It seems like once a project gets to a certain size, magic strings – that is, character values hard-coded into the application – become inevitable.  When a piece of software needs to read data generated by another piece of software, the use of magic strings becomes a requirement for sanity.  The common pattern for dealing with magic strings is to encapsulate them in a constant:

        public const String FRUITS_APPLE = "Apple";

That works fine when you have a small number of constants, but what happens when you have 10, 20, or more?  Furthermore, what do you do when subsets of them are logically related to each other?  One approach is to name them according to that logical group:

        public const String APPLES_RED_DELICIOUS = "Red Delicious";
        public const String APPLES_GALA = "Gala";
        public const String APPLES_FUJI = "Fiji";

        public const String ORANGES_BLOOD = "Blood";
        public const String ORANGES_NAVEL = "Navel";
        public const String ORANGES_VALENCIA = "Valencia";

        public const String LEMONS_MEYER = "Meyer";
        public const String LEMONS_EUREKA = "Eureka";
        public const String LEMONS_LISBON = "Lisbon";

What I’d really prefer to do is to create enumerations for each of these groups.  The problem is an enumeration can’t have string values behind it:

        public enum Apples
        {
            RedDelicious = "Red Delicious",
            Gala = "Gala",
            Fuji = "Fuji"
        }

This will return a compile-time error of "Cannot implicitly convert type ‘string’ to ‘int’".

I’ve gotten around this in the last few years by creating one or more subclasses, one for each logical grouping, and then creating constants within.  I call these "constants-classes":

        public class Apples
        {
            public const String RedDelicious = "Red Delicious";
            public const String Gala = "Gala";
            public const String Fuji = "Fiji";
        }
        public class Oranges
        {
            public const String Blood = "Blood";
            public const String Navel = "Navel";
            public const String Valencia = "Valencia";
        }
        public class Lemons
        {
            public const String Meyer = "Meyer";
            public const String Eureka = "Eureka";
            public const String Lsibon = "Lisbon";
        }

In code, then, I can access these values just like I would the values of a true enumeration:

        String CurrentApple = Apples.RedDelicious;
        String CurrentOranage = Oranges.Navel;

This pattern has served me well over the years, but I ran into a new challenge with it in my current project.  The application imports XML messages pulled off of a queue, and there are a small number of major types of entities that need to be processed.  (For the purposes of this post, I’ll continue my fruit analogy and say that the types of entities are apples, oranges, and lemons; I’m not really writing a fruit app.)

Large chunks of the XML for these different types are actually the same, so I built a series of System.Xml.Linq.XElement extension methods that operate on a specific slice of the XML.  When I import a given entity – let’s say a lemon – I break off the appropriate piece of the full XML document for that lemon, then call the appropriate extension method to de-serialize it and turn it into a strongly-typed object (“FruitProperties” in this case):

        public static FruitProperties ExtractProperties(this XElement XmlToProcess)
        {
        }

The XML was largely made up of collections of <Attribute /> blocks, each of which contained the same basic components.  One of these components was the "name" of the attribute – a unique handle that will never change, and allows me to safely identify the various bits of data for an entity.  I defined several constants-classes to centralize these names. 

Let’s say I had attributes like "PeelTexture", "Color", and "HasSeeds".  The challenge arose when I realized that although all of my entity types had these attributes, the actual attribute names used in the apple-XML versus the orange-XML were different.  For example, the PeelTexture attribute might appear as "Peel_Texture" for an apple, but "Orange_Peel" for an orange.   
   
My first attempt to address this was to try to move the constants to an “IFruit” interface.  My thought was to define the template for the constants, and then I would "implement" them (assign the real, apple-, orange-, and lemon-specific values) in the concrete classes that implemented that interface.  However, I got another compile-time error because C# (and presumably all .NET languages) don’t allow interfaces to have static members, fields, or properties.

I tried several other approaches before I arrived at this slightly-hacky solution.  First, I defined my constants-classes to hold all of my entities’ unique values:

        public class Constants
        {
            public class Apple
            {
                public const String PeelTexture = "Peel_Texture";
                public const String Color = "Color";
                public const String HasSeeds = "Apple_HasSeeds";
            }
            public class Orange
            {
                public const String PeelTexture = "Orange_Peel";
                public const String Color = "Orange_Color";
                public const String HasSeeds = "Has_Seeds";
            }
            public class Lemon
            {
                public const String PeelTexture = "PeelTexture_2";
                public const String Color = "Color_Lemon";
                public const String HasSeeds = "Has_Any_Seeds";
            }
        }

I then modified my generic ExtractProperties method to take a Type object.  This object would be the actual constants-class for the entity being processed:

        public static FruitProperties ExtractProperties(this XElement XmlToProcess, Type FruitConstants)
        {
        }

This method would be invoked as follows:

        XDocument MyDocument;
        FruitProperties MyProperties;

        // Load XML into MyDocument here

        XElement SliceToImport = MyDocument.Element("Root").Element("Properties");
        MyProperties = SliceToImport.ExtractProperties(typeof(Constants.Apple));

Within the ExtractProperties method, I then naively tried to do this to get the actual value of the constant:

        String FieldToExtract = FruitConstants.PeelTexture;

But ExtractProperties had no idea what "FruitConstants" type really was, so this also throws a compile-time error.  So, I then created a simple enumeration that became my "template" for my constants-classes.  This enumeration’s members would have the same name as the constants defined in my classes:

        public enum FruitConstantsTemplate
        {
            PeelTexture,
            Color,
            HasSeeds
        }

I could use that template – and a little trust – to pull the desired value out of the constants-class by its name using reflection.  I wrote a custom function to do just that:

        public static String GetFieldName(Type T, String ConstantName)
        {
            FieldInfo CandidateConstant;

            // Validate the parameters being passed in
            ConstantName = (ConstantName ?? "").Trim();
            if (String.IsNullOrEmpty(ConstantName)) { throw new ConstantException(); }

            if (T == null) { throw new ClassException(); }

            // Get the list of constants from type T using reflection
            var Constants = T.GetFields(BindingFlags.Public | BindingFlags.Static | BindingFlags.FlattenHierarchy);

            // Find the one I'm looking for, based on name.
            CandidateConstant = Constants.FirstOrDefault(c => c.Name == ConstantName);
            if (CandidateConstant == null) { throw new ConstantNotFoundException(ConstantName, T.Name); }
            return (String)CandidateConstant.GetValue(CandidateConstant);
        }

I modified ExtractProperties to use this new function:

            String FieldToExtract = GetFieldName(typeof(Constants.Apple), FruitConstants.PeelTexture.ToString());

I say "a little trust" because this function only returns a constant’s value if both of the following hold true:

  1. the FruitConstantsTemplate defines it; and
  2. the constants-class passed in as type T contains it

This sort of thing is what an interface would enforce for methods (for example) at compile-time.  With this approach, however, there’s nothing to stop me from adding a value to the enumeration, and forgetting to add it to the constants-classes (or vice versa).  There’s also nothing at compile time to stop me from passing in a completely invalid type to GetFieldName(), such as "String" or "DateTime" (again, something a true interface would catch at compile-time).

This approach does have its share of advantages, though:

  1. It allows me to concentrate the "generic-ness" in one function (rather than having the same basic logic duplicated in several functions, differing only by the constants it was using).
  2. It also allows me to define and continue using the class-constants just as I have always done.  The only catch is when I add a constant, I have to remember to update the template with it.

***

While I have a functional solution, I also have a nagging thought.  This is organic solution, grown (no pun intended) around the constraints of the framework and the language, but is there a better way to accomplish what I’m trying to do?

A question to revisit for my next project.

September 9, 2013 Posted by | Visual Studio/.NET | Comments Off

Queue them up! Unit testing HttpClient

Early in my current project, I was looking for a way to test some logic that relied on HttpClient.PostAsync.  I was writing a routine that would process items coming off a queue that was exposed via a series of REST services.  Subscribing to the queue, pulling messages down, and cleaning the subscription up once the queue was empty all required calls to the services, and in most cases several calls.  Ideally I’d be able to mock the calls to HttpClient.PostAsync out, but I can’t because that method isn’t virtual.  The usual way to handle methods like that is to build an interface that I CAN mock out, and then build a wrapper-implementation of that interface which calls HttpClient.PostAsync.  My unit tests would use a mock of that interface, and the real code would use my wrapper.  Adding interfaces adds flexibility to a piece of software, at the cost of readibility and maintainability, so before I went that route I wanted to see if there was a better way.

I came across this post by Gabriel Perez where he shows how to build a fake handler that returns an “injected” response when PostAsync is invoked.  (He credits Glenn Bock for the original source.)  This “russian doll model” as he calls it looked very promising.  In fact, I thought I could even extend it to inject the responses from a queue, allowing me to line them for a specific scenario, and then test my code against it.

I decided that a simple list would suffice for the queue.  FakeHandler would just keep track of which responses it had already handed out:

// FakeHandler, adapted from: http://perezgb.com/2012/02/21/web-api-testing-with-httpclient
        public class FakeHandler : DelegatingHandler
        {
            public List<HttpResponseMessage> Responses { get; set; }
            private int _Index;
public FakeHandler() : base()
            {
                this.Responses = new List<HttpResponseMessage>();
                this._Index = -1;
            }

            protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
            {
this._Index++;
                if (this._Index >= this.Responses.Count) { return Task.Factory.StartNew(() => (HttpResponseMessage)null); }
                return Task.Factory.StartNew(() => Responses[this._Index]);
            }
        }

Here is how a test would look using this structure:

        [Test]
        public void SomeTest()
        {
            HttpResponseMessage ConfiguredResponse;
            HttpClient ConfiguredClient;
            FakeHandler NewHandler;
            QueueProcessor MyProcessor;

            // Configure the response.  Set properties (headers, etc.) as needed.
            ConfiguredResponse = new HttpResponseMessage();

            // Build a handler around this response
            NewHandler = new FakeHandler() { InnerHandler = new HttpClientHandler() };
            NewHandler.Responses.Add(ConfiguredResponse);

            // Create a client object around this handler
            ConfiguredClient = new HttpClient(NewHandler);

            // Pass in the pre-configured client to the class under test (dependency injection)
            MyProcessor = new QueueProcessor(ConfiguredClient);

            // Test the method
            var Results = MyProcessor.DoSomething();

            // TODO: Evaluate the results
        }

For “real” use, I would simply pass in a new HttpClient() object to the QueueProcessor constructor.  This all worked quite well to mock out the responses, but my tests could only evaluate what came out at the very end.  I also wanted to make sure the individual responses were being handled properly.

I could have simply injected a set of Asserts into FakeHandler.SendAsync, but I wanted to build it so it could potentially handle completely different tests each time.  To do that, I added an event handler called “OnEntryVerificationMethod”.  This became a property of the FakeHandler class that I could define in my unit test, which would be run at a known point in the execution (on entry), and would have access to both the current and previous responses (see bolded additions below).

// Define the prototype for the delegate that will perform our validation
        public delegate void VerifyOnEntry(HttpRequestMessage CurrentRequest, HttpResponseMessage PreviousResponse);

        // FakeHandler, adapted from: http://perezgb.com/2012/02/21/web-api-testing-with-httpclient
        public class FakeHandler : DelegatingHandler
        {
            public List<HttpResponseMessage> Responses { get; set; }
            private int _Index;

            // Define a delegate that allows me to pass in a custom function at runtime
            public VerifyOnEntry OnEntryVerificationMethod;

            public FakeHandler() : base()
            {
                this.Responses = new List<HttpResponseMessage>();
                this._Index = -1;
            }

            protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
            {
                // If a custom function was defined, invoke it, passing in the parameters to be verified.
                if (OnEntryVerificationMethod != null)
                {
                    OnEntryVerificationMethod(request, (this._Index < 0 ? (HttpResponseMessage)null : Responses[this._Index]));
                }

                this._Index++;
                if (this._Index >= this.Responses.Count) { return Task.Factory.StartNew(() => (HttpResponseMessage)null); }
                return Task.Factory.StartNew(() => Responses[this._Index]);
            }
        }

I could define this in my unit test using an anonymous function:

            int NumberOfMessagesProcessed = 0;
            NewHandler.OnEntryVerificationMethod = (CurrentRequest, PreviousResponse) =>
            {
                NumberOfMessagesProcessed++;

                if (PreviousResponse == null) { return; }

                switch (NumberOfMessagesProcessed)
                {
                    case 1:
                        // TODO: Perform tests for the first response processed
                        break;

                    case 2:
                        // TODO: Perform tests for the second response processed
                        break;
                }
            };

Now I had a window into FakeHandler’s execution, and could inspect anything I needed.

If HttpClient.PostAsync was virtual (and therefore directly mockable), it would have made testing one call far easier, but trying to simulate multiple calls in a row would probably have pushed me into this structure anyway.

You could argue that in lining up multiple responses like this I’m trying to test too much; that what I should be doing is setting up everything for a given scenario (e.g., responses have already come back as “fail” twice), and then pass in the one I really want to test (the third attempt is a success).  However, I think that would result in a more complicated code base because I would have to make several internal properties available to my test (like the number of times an HttpClient.PostAsync call results in a failure), or make more extensive use of interfaces, or both.  Lining up a series of responses, and then testing that greater scenario, is a more straightforward approach.

Sometimes, I will totally trade having code that is awesomely-flexible and unit test-pure for code that I can more easily get my head wrapped around.

September 5, 2013 Posted by | Visual Studio/.NET, Web API | Comments Off

Now where did I put that day? .NET Date Math, and Reversibility

This past week, I hit an interesting quirk with dates in .NET (or possibly it’s a quirk with the Gregorian calendar).  I started by subtracting 6 months from "today" to get a new date, and then later would add 6 months back to make sure I would get "today" again.  This scenario was part of a very simple unit test that I had written weeks ago, and had been passing fine for all of that time.

That is, until "today" was 8/29/2013.  On that day, my test failed.

If "today" were 8/15/2013, then subtracting 6 months would yield 2/15/2013 – just what I’d expect;

            DateTime InitialDate, NewDate;
            InitialDate = DateTime.Parse("8/15/2013");
            NewDate = InitialDate.AddMonths(-6);
            // NewDate will be 2/15/2013

However, if I started with 8/29/2013, there’s a snag:

            DateTime InitialDate, NewDate;
            InitialDate = DateTime.Parse("8/29/2013");
            NewDate = InitialDate.AddMonths(-6);
            // NewDate will be 2/28/2013

There is no 29th day of February in 2013, so to return a valid date .NET returns 2/28/2013 instead.  What happens when I add 6 months to 2/28/2013?

            DateTime InitialDate, NewDate;
            InitialDate = DateTime.Parse("2/28/2013");
            NewDate = InitialDate.AddMonths(6);
            // NewDate will be 8/28/2013

I get 8/28/2013 – not what I originally started with.  I actually end up losing a day due to the equivalent of a rounding error for calendars.

What if I were to go in the other direction originally – start with 8/29/2013 and ADD 6 months?

            DateTime InitialDate, NewDate;
            InitialDate = DateTime.Parse("8/29/2013");
            NewDate = InitialDate.AddMonths(6);
            // NewDate will be 2/28/2014

As before, since February 2014 has no 29th day, .NET gives me the next oldest day – the 28th.

The lesson here is that date-math using MONTHS is not always a reversible operation.  If I were to switch to adding and subtracting DAYS, however, that appears to be reversible:

            DateTime InitialDate, NewDate;
            InitialDate = DateTime.Parse("8/29/2013");
            NewDate = InitialDate.AddDays(-183).AddDays(183);
            // NewDate will be 8/29/2013

This isn’t limited to February, either.  Any time my starting month has more days than the month I end up with, this will happen (for example, October and April, December and June).

Ah, fun with dates.

September 2, 2013 Posted by | Visual Studio/.NET | Comments Off

Reducing the Tedium: Generalized Unit Tests via Reflection

In the course of developing a new class, especially one that is tied to Castle ActiveRecord, I will usually add one or more String properties.  Unless there is some reason to make these nullable, I usually modify the getters to return either an empty string or a valid value.  Knowing that the property will only be in one of these two states makes it easier to use that property in expressions like MyObject.MyProperty.Contains("blah").  I don’t have to worry about a null reference exception here if I know MyProperty can’t return a null.

To ensure that the properties are up to snuff, I will invariably write a series of five unit tests, per property:

1) Initializing the class – property should return empty string
2) Setting the property to null – property should return empty string
3) Setting the property to an empty string – property should return empty string
4) Setting the property to some whitespace – property should return empty string
5) Setting the property to a valid value – property should return that value.

As you can imagine, writing these five for each String property gets tedious.  A couple of weeks ago, I wondered if I could automate these tests – specifically, could I write something that would automatically and dynamically check every String property on a class to make sure each one passed these five conditions?

As it turns out, the answer is a resounding yes.  Here is my NUnit test for Strings:

 

    [TestFixture]
    public class PropertyTests
    {
        Type[] _TypesToCheck = { 
                                   typeof(PropertyTestsViaReflection.NS_A.ClassA), 
                                   typeof(PropertyTestsViaReflection.NS_B.ClassB),
                                   typeof(PropertyTestsViaReflection.NS_C.ClassC)
                               };

        [Test]
        public void StringProperties_DefaultToEmptyString()
        {
            String TestValue, ClassName;
            PropertyInfo[] ClassProperties;
            Object ClassInstance;

            for (int i = 0; i < this._TypesToCheck.Length; i++)
            {
                ClassName = this._TypesToCheck[i].Name;
                ClassProperties = this._TypesToCheck[i].GetProperties();
                ClassInstance = Activator.CreateInstance(this._TypesToCheck[i]);

                System.Diagnostics.Trace.Write(String.Format("Now testing {0}...", ClassName));

                foreach (var PropertyUnderTest in ClassProperties.Where(p => p.PropertyType == typeof(String)))
                {
                    TestValue = (String)PropertyUnderTest.GetValue(ClassInstance, null);
                    Assert.IsEmpty(TestValue, String.Format("{0}.{1} did not initialize properly", ClassName, PropertyUnderTest.Name));

                    PropertyUnderTest.SetValue(ClassInstance, null, null);
                    TestValue = (String)PropertyUnderTest.GetValue(ClassInstance, null);
                    Assert.IsEmpty(TestValue, String.Format("{0}.{1} did not handle null properly", ClassName, PropertyUnderTest.Name));

                    PropertyUnderTest.SetValue(ClassInstance, "", null);
                    TestValue = (String)PropertyUnderTest.GetValue(ClassInstance, null);
                    Assert.IsEmpty(TestValue, String.Format("{0}.{1} did not handle an empty string properly", ClassName, PropertyUnderTest.Name));

                    PropertyUnderTest.SetValue(ClassInstance, "  ", null);
                    TestValue = (String)PropertyUnderTest.GetValue(ClassInstance, null);
                    Assert.IsEmpty(TestValue, String.Format("{0}.{1} did not handle a blank string properly", ClassName, PropertyUnderTest.Name));

                    PropertyUnderTest.SetValue(ClassInstance, "abc123", null);
                    TestValue = (String)PropertyUnderTest.GetValue(ClassInstance, null);
                    Assert.AreEqual("abc123", TestValue, String.Format("{0}.{1} did not handle a valid string properly", ClassName, PropertyUnderTest.Name));
                }

                System.Diagnostics.Trace.WriteLine("completed");
            }
        }
    }

First, I define a hard-coded list of classes called "_TypesToCheck".  (I did this more for convenience than anything else; at the end of this post I suggest a better way.)  For each of these types, I grab the name of the class (to be used with the error messages), the list of properties to check, and instantiate an instance of the class.

I boil the list of properties down to just the ones that are of type String, and then iterate over each of those, running my five tests.  If any of these tests fail for any of the properties for any of the classes, the test reports the failure and stops.

I pieced this method together from several sources:


In addition to checking the String properties, I also perform a couple of tests on any properties with the name "ID".  This is an ActiveRecord standard, and I want to make sure that the ID properties are 0 initially, and that it can’t be assigned a negative value (this would be just another test in the same fixture).  The basic structure is the same, but instead of looking for properties of type “String”, I boil my list down to properties with the name “ID”":

        [Test]
        public void IDProperties_DefaultTo0()
        {
            long TestValue;
            String ClassName;
            PropertyInfo[] ClassProperties;
            Object ClassInstance;

            for (int i = 0; i < this._TypesToCheck.Length; i++)
            {
                ClassName = this._TypesToCheck[i].Name;
                ClassProperties = this._TypesToCheck[i].GetProperties();
                ClassInstance = Activator.CreateInstance(this._TypesToCheck[i]);

                System.Diagnostics.Trace.Write(String.Format("Now testing {0}...", ClassName));

                foreach (var PropertyUnderTest in ClassProperties.Where(p => p.Name.Equals("ID", StringComparison.CurrentCultureIgnoreCase)))
                {
                    TestValue = (long)PropertyUnderTest.GetValue(ClassInstance, null);
                    Assert.AreEqual(0, TestValue, String.Format("{0}.{1} did not initialize properly", ClassName, PropertyUnderTest.Name));

                    PropertyUnderTest.SetValue(ClassInstance, 0, null);
                    TestValue = (long)PropertyUnderTest.GetValue(ClassInstance, null);
                    Assert.AreEqual(0, TestValue, String.Format("{0}.{1} did not handle being set to 0 properly", ClassName, PropertyUnderTest.Name));

                    PropertyUnderTest.SetValue(ClassInstance, -1, null);
                    TestValue = (long)PropertyUnderTest.GetValue(ClassInstance, null);
                    Assert.AreEqual(0, TestValue, String.Format("{0}.{1} did not handle being set to a negative properly", ClassName, PropertyUnderTest.Name));
                }

                System.Diagnostics.Trace.WriteLine("completed");
            }

        }

 

These tests certainly don’t take care of all testing for a class, but it certainly does handle most of the basics.  When I add a new class, I simply update the _TypesToCheck array to reference it.  If I add a new property to one of the covered classes, the test fixture picks up on that immediately and tells me when the property isn’t behaving properly.

This is only a first step.  I can easily see a couple of enhancements that might prove useful:

  • Instead of looking at the property name or type, attach a validator (custom or otherwise) attribute that will identify what kinds of tests to perform on that property.  If it is a String property, run the String tests; if it is a Date property, make sure the date is not DateTime.MinValue, etc..
  • Be able to decorate the classes, and then have the test fixture reflect over the entire assembly to find the classes to test.  This would replace the need for a hard-coded array of assemblies.

Enjoy!

July 3, 2013 Posted by | Visual Studio/.NET | Comments Off

Wait your turn! Async and Await

It’s all about the bubbles.  Let me explain.

I was trying to implement something that I thought would be more efficiently done asynchronously.  Since I was using .NET 4.0 with the "Async for .NET Framework 4" NuGet package, I had access to the new "async" and "await" keywords.  These were designed to make it easier to kick off an asynchronous operation.  I was about to find out, however, that these weren’t silver bullets – I still had to understand what was going on to use them properly.

For illustrative purposes only, I’ll use a boiled-down version of what I was trying to implement.  This is a simple console application that tries to do some “work” (really just some calls to Thread.Sleep()), and records the order that it implements the steps.

10

First, the simple case – good ole’ fashioned synchronous:

        private static void Option1()
        {
            Option1_Step1();
            Console.WriteLine("3");
            Option1_Step2();
            Console.WriteLine("6");
        }
        private static void Option1_Step1()
        {
            Console.WriteLine("1");
            DoSomeSychronousWork(500);
            Console.WriteLine("2");
        }
        private static void Option1_Step2()
        {
            Console.WriteLine("4");
            DoSomeSychronousWork(500);
            Console.WriteLine("5");
        }

The DoSomeSynchronousWork() routine looks like this:

        private static void DoSomeSychronousWork(int Milliseconds)
        {
            System.Threading.Thread.Sleep(Milliseconds);
            return;
        }

Which outputs the checkpoint numbers 1-6 in order:

20

My first attempt to run Step 1 and Step 2 asynchronously, however, didn’t work out as I had expected:

        private static void Option2()
        {
            Option2_Step1();
            Console.WriteLine("3");
            Option2_Step2();
            Console.WriteLine("6");
        }
        private static async void Option2_Step1()
        {
            Console.WriteLine("1");
            await DoSomeAsynchronousWork(500);
            Console.WriteLine("2");
        }
        private static async void Option2_Step2()
        {
            Console.WriteLine("4");
            await DoSomeAsynchronousWork(500);
            Console.WriteLine("5");
        }

My initial, naive interpretation of "asynchronous operations don’t block the thread" was that if I slapped the "await" keyword onto a method call, it would execute that method on a new thread, and put the rest of my application to sleep, freeing the thread that it had been on to be used by something else on the computer.  Then, when my “awaitable" method returned, the computer would wake my program back up to continue where it left off.  No blocking, right?

I’m still not certain how right this interpretation was, but it definitely was not 100%.  I doubt I even made it past the 50s.  Here is what my program was now outputting:

30

Excellent.  Let’s just execute all of that methods that we can as fast as we can, and the awaitable ones will just catch up.  Mmmm… yeah, that’s really not going to work for me.

As I dug into it, and consulted Stephen Cleary’s excellent post, "Async and Await", I managed to piece together what was going on here.

 

First, the Main() routine calls Option2(), and execution begins.

32

Control then goes to the first step – Option2_Step1().

33

Which writes out the first checkpoint.  Next, it begins execution of the asynchronous work item.

34

The DoSomeAsynchronousWork() function is as follows:

        private static Task DoSomeAsynchronousWork(int Milliseconds)
        {
            return (new TaskFactory()).StartNew(() => System.Threading.Thread.Sleep(Milliseconds));
        }

Now, the work here has only STARTED.  Sync we said wanted to await this method, execution of Option2_Step1() will now be paused, waiting for DoSomeAsynchronousWork to return.  Control will now be passed back to the calling function, Option2().

35

Where it will charge forward onto the next piece of logic, checkpoint #3.  Then it will continue on to Option2_Step2().

36

Where it will then write out checkpoint #4, and start yet another asynchronous task.

37

With that second asynchronous task started, it will immediately return to the calling function, Option2(), and continue on by printing out checkpoint #6.

38

With Option2() now complete, it returns to the Main() function, and where it prints out the "Press [Enter] to run again." prompt, and waits for the user to press "Enter".

39

A short time later, the first asynchronous task, started in Option2_Step1(), completes and execution is started back up for that method, which results in checkpoint #2 being written out.  Then finally, the asynchronous task that was started in Option2_Step2() completes, and execution is started back up for that method, which results in checkpoint #5 being written out.

***

What I came to realize was that the methods I was using "async" on – Option2_Step1() and Option2_Step2() – formed a kind of "bubble".  Things within the bubble would be executed serially, but asynchronously. 

The serial part means that checkpoint 1 would always be reached out before checkpoint 2, and checkpoint 4 would always be reached before checkpoint 5. 

The asynchronous part means when the execution reaches the first work item (between checkpoints 1 and 2) the await keyword tells .NET to start that work, AND THEN RETURN AND KEEP GOING with the rest of the program – in this case, it would return to the Option2() method, print out checkpoint 3, etc.  In other words, when things inside the bubble are paused, control is passed back, to whatever called the bubble.

This is where the "doesn’t block" facet comes into play – when something asynchronous is started .NET will return control to the calling method, putting the current method on pause (so to speak).  When the work item is finished, .NET will start that method back up again, right where it left off.

So, how can I ensure that Step1 will complete before Step2 does?  The solution I landed on was to move the asynchronous nature of this program up a level:

        private static async void Option3()
        {
            await Option3_Step1();
            Console.WriteLine("3");
            await Option3_Step2();
            Console.WriteLine("6");
        }
        private static async Task Option3_Step1()
        {
            Console.WriteLine("1");
            await DoSomeAsynchronousWork(500);
            Console.WriteLine("2");
        }
        private static async Task Option3_Step2()
        {
            Console.WriteLine("4");
            await DoSomeAsynchronousWork(500);
            Console.WriteLine("5");
        }

Here, I’ve declared Option3() – the top level function – async as well.  With that in place, Option3_Step1() and Option3_Step2() should be called serially.  As before, Main() calls Option3(), and we begin by calling Option3_Step1().

42

That immediately leads to the first checkpoint.

43

And the first asynchronous piece of work.

44

Which means execution of Option3_Step1() is now paused, and control is returned to the calling function, Option3().  However, since we’re awaiting Optino3_Step1(), control is passed out ANOTHER level, back to Main(), where it prints out the "Press [Enter] to run again." prompt, and waits for the user to press "Enter".  At that point, there is nothing more that can be done, so the entire program waits.

When our first bit of asynchronous work completes, it picks back up where it left off Option3_Step1():

45

Which means checkpoint 2 is now printed out.  That’s the end of Option3_Step1(), so it returns to Option3(), prints out checkpoint 3, and begins execution of Option3_Step2():

46

Checkpoint 4 is printed out, and then the second bit of asynchronous work is started.

47

Again, execution is paused here, and control is returned to the calling function, Option3(), and then paused there and again passed back to Main().  Since the rest of Main() has already executed, nothing more happens.  The program is simply paused until the second piece of asynchronous work is completed.

When it completes, Option3_Step2() picks back up, and checkpoint 5 is written out.

48

And then checkpoint 6.

49

Here is the output, in aggregate:

40

So, by making Option3() asynchronous as well, we eliminate most of the unexpected behavior – things, for the most part, happen in order*.  In fact, doing this drives home another point that Cleary made in an MDSN article titled "Best Practices in Asynchronous Programming": trying to mix synchronous and asynchronous code is tricky at best.  It’s better to make something asynchronous "all the way down".

The full solution for the sample used here can be found in the AsyncAndAwait.zip archive at http://Tinyurl.com/MarkGilbertSource.  You’ll need Visual Studio 2012 Update 3 to run it (I built it using the Express version).

 

 

* For the purposes of this demonstration, the “Press [Enter] to run again.” is executing out of order.  In my real program, the Main() routine didn’t have anything else to do other than wait for the steps to complete, so on the surface appeared a lot less weird.  Control was still being passed back to the Main() however, and I would have to be very careful about adding anything to my program.

July 1, 2013 Posted by | Visual Studio/.NET | Comments Off

Follow

Get every new post delivered to your Inbox.