Quickduck

Short Cut Keys to Run Tests:

• Ctl R, T: Run Tests in Current context (namespace, class, and method – ie. Based on where your cursor is within a file it determines the tests to run)
• Ctl R, C: Run Tests in Current Test Class
• Ctl R, N: Run Tests in Current Namespace
• Ctl R, S: Run All Tests in Solution
• Ctl R, D: Run the Tests in the Last Test Run
• Ctl R, F: Run the Failed Tests of the Last Test Run

After having 9 months off from doing .net (travelling, bumming and then a 3 month contract role as an architect in a coldfusion shop) I finally got myself a role doing what I love doing best – playing with .net and c#.

In the last 4 weeks I’ve been researching and prototyping apps that use

• .net 3.5
• ado.net entity framework
• ado.net data services – including .net, ajax and silverlight client libraries
• Silverlight 2.0
• Visual Studio for Software Testers – Web Testing

It’s been awesome to have the time and resources to touch across all of these technologies to enjoy their benefits and to loath the limitations.

All in all I reckon all of the technologies are a great addition to the .net stack and look forward to seeing them mature with each new release.

I look forward to documenting my findings as I find time to re-work them into don’t-give-away-IP examples.

We recently ran into this problem where we discovered that running our VS unit tests was killing IIS.

As with all problems, I like to break things down to the simplest scenario I can find and as such created a brand new unit test that did nothing to see if that still caused the problem – it did.

So knowing that it had nothing to do with any code that was web dependent I knew to start looking elsewhere.

Turns out the problem is caused by enabling code coverage on projects that are dependent on IIS – e.g. a web project.

The simple solution is to disable code coverage on the problem-causing project OR alternately remove the dependency on IIS by modifying it to use the in-built Cassini web server.

Have you ever found yourself using c# const values to remove the risks associated with using copies of string literals throughout your code base?

Example:

public static class VehicleTypesConsts {
 public const string Car = 'Car';
 public const string Motorbike = 'Motorbike';
 public const string Truck = 'Truck';
}

In a situation like this it’s quite easy to replace these const values with a C# enum and use the System.Enum.GetName static method to return Enum properties name.

public enum VehicleTypesEnum {
  Car,
  Motorbike,
  Truck,
}

Calling

Enum.GetName(typeof(VehicleTypesEnum), VehicleTypesEnum.Car)

will return the string value “Car”.

Looking at this syntax you could be forgiven for thinking why bother? It’s too much hassle and looks puss.

Well using C# 3.0 extension methods you can provide a convenience method to all Enums to return the enum string representation.

public static class EnumExtensions {
  static public string GetName(this Enum enumeration) {
    return Enum.GetName(enumeration.GetType(), enumeration);
  }
}

Now you can just write:

VehicleTypesEnum.Car.GetName()

and it will return the string “Car”.

The following test method shows illustrates the varying ways to achieve the same result:

        [TestMethod]
        public void Test()
        {
            string expected = 'Car';
            Assert.AreEqual(expected, VehicleTypesConsts.Car);
            Assert.AreEqual(expected, Enum.GetName(typeof(VehicleTypesEnum), VehicleTypesEnum.Car));
            Assert.AreEqual(expected, VehicleTypesEnum.Car.GetName());
        }