Month: March 2011

Permanent Deployment with Wix

There are certain situations where you may want to deploy files permanently to a computer so that they persist through uninstall/re-installs or upgrades. A typical situation in my business is we’ll deploy a config file with default settings. If the settings change, we don’t want them to be lost or overwritten during an upgrade.

By making a very simple modification to your Wix installer, we can get this behavior.

<Component Id="C_Settings.config" Guid="*" NeverOverwrite="yes" Permanent="yes">

The NeverOverwrite attribute ensures that the file will not be overwritten during an upgrade, and the Permanent attribute will cause the file to remain in the program is uninstalled. Perfect!

Where’s My Windows Phone Update?

I have been a Windows Phone user since WP7 was released at the end of last year. From the very beginning, there have been rumors of updates coming in Janurary, February, March… but now, on the brink of April, I’m still yet to get any updates.

I’m not upset about the delay because I really don’t have any major gripes and am generally happy with my phone. At the same time, I want them updates!

Last week, I was excited to see Microsoft introduce a “Where’s my phone update?” site where you can check on the status of the phone updates by region and phone model. This is great because I can check the website periodically to see when it moves out of Testing, to Scheduling, and finally to Delivering Update.

Here’s the link: http://www.microsoft.com/windowsphone/en-us/features/update-schedules.aspx

Getting Started with Linq to XML

I was out at a customer site a few weeks ago and needed to whip up a quick program to extract a large number of values from an XML document. To me, the obvious way to accomplish this task was to write a quick application to read the XML, parse the values, and write them to a separate document. Linq to XML made this cumbersome task very easy, and I was reminded of just how amazing Linq to XML really is.

Linq to XML is one of the best things to happen to XML in recent history, but I think there are still a lot of developers out there who are either not familiar with Linq or are just comfortable working with XML using the same techniques that they always have. I haven’t done an extensive amount of XML processing in my career, but I haven’t exactly been a stranger to it, either. In my opinion Linq to XML makes working with XML downright trivial. If you haven’t looked into it, I definitely recommend that you do!

For the purposes of demonstration, consider an XML file “data.xml” with the following contents:

<Library>
  <Books>
    <Book>
      <Title>A Study in Scarlet</Title>
      <Author>Sir Arthur Conan Doyle</Author>
    </Book>
    <Book>
      <Title>A Thief in the Night</Title>
      <Author>E. W. Hornung</Author>
    </Book>
  </Books>
</Library>

Using Linq to XML, you can write code to parse the contents of the file into easy-to-use objects.

var xml = XDocument.Load(@"data.xml");
var data = from n in xml.Descendants("Book")
           select new
           {
               Author = n.Element("Author").Value,
               Title = n.Element("Title").Value
           };

foreach (var d in data)
    Console.WriteLine("{0},{1}", d.Title, d.Author);

Looking for a specific value in the XML? Just modify your Linq query!

var xml = XDocument.Load(@"data.xml");
var data = from n in xml.Descendants("Book")
           where n.Element("Author").Value == "E. W. Hornung"
           select new
           {
               Author = n.Element("Author").Value,
               Title = n.Element("Title").Value
           };

So cool!

your.address+tips@gmail.com

I was speaking with some co-workers earlier this week, and someone mentioned you own all variations of your Gmail email address that contain different period placements. This means that if you register joe.blow@gmail.com, you also own joeblow@gmail.com, j.o.e.blow@gmail.com, and joe.bl.ow@gmail.com. You can verify this two ways. First, you can log in to Gmail using any of these variations; it will still take you to the same inbox you’re used to seeing. Second, you can send an email to any of these variations, and you’ll receive it just like you’d expect.

The usefulness of this is questionable, but I still thought it was fun and interesting to know. And maybe you wished you could make your gmail more specific (for example, nycanal@gmail.com could use ny.canal@gmail just so there’s no confusion).

This reminded me of another interesting trick that you can do with your Gmail account. Google let’s you append “+” and text to your email address. I love using this when registering for different things. When the email comes in, the tag will be included. So, if you starting getting spam in your inbox sent to joe.blow+bestbuy@gmail.com, you’ll know where they got your email address. More importantly, you can easily set up an email filter for messages sent to that address so you don’t need to worry about them anymore. The same is true for the period-placement variations, too; you’ll receive the emails with the To line containing the address they were sent to, so you can filter or what-not as you please.

Unit Testing: Hello, World!

The “Hello, World!” of unit tests typically involves a function that accepts inputs and provides an expected output. Consider the following Calculator class:

public class Calculator
{
    public static int Add(int x, int y)
    {
        return x + y;
    }
    public static int Divide(int dividend, int divisor)
    {
        return dividend / divisor;
    }
}

Writing unit tests for the Add method is simple and straightforward. We can declare our inputs, come up with the expected output, execute the function and verify the result.

[TestMethod]
public void AddTest()
{
    int x = 1;
    int y = 2;
    int expected = 3;
    int actual = Calculator.Add(x, y);
    Assert.AreEqual(expected, actual);
}

The Add method is so simple that there isn’t much more you can do with it, so let’s take a look a the Divide method. Similarly to the Add method, we can write a simple unit test to verify our core behavior.

[TestMethod]
public void DivideTest()
{
    int dividend = 10;
    int divisor = 2;
    int expected = 5;
    int actual = Calculator.Divide(dividend, divisor);
    Assert.AreEqual(expected, actual);
}

Now that we have that out of the way, let’s deal with an exception case: division by zero. Before we can test or code, we must decide what we want our application to do in this scenario. I have decided that application should simply throw the default divide-by-zero exception, so let’s write a test for it to help ensure that this functionality isn’t lost with future changes.

[TestMethod]
[ExpectedException(typeof(System.DivideByZeroException))]
public void DivideTest_DivisionByZero()
{
    int dividend = 10;
    int divisor = 0;
    int actual = Calculator.Divide(dividend, divisor);
}

By decorating the test method with the ExpectedException attribute, the test will fail if the exception is not thrown.

You can see that writing unit tests for these something-in-something-out functions can be very easy. Try to test as many different scenarios as you can come up with. Some common situations to consider are minimums, maximums, default values, and nulls. Write skeleton tests up-front to help you remember relevant scenarios to be handled by your code.

Unit Testing Guidelines

There always seems to be a lot of discussion regarding the whens and hows of unit testing. These can be challening topics when you’re getting started with unit testing, and I wanted to document some of the rules, guidelines, and lessons-learned that I apply when writing my own tests.

Keep it simple.

If it seems like testing a piece of functionality is really hard, there’s probably an easier way. One of the keys to writing good unit tests is having testable code. (Duh, right?) Well, one of the best skills that you can have is the ability to take a block of untestable code and transform it into a well-tested masterpiece. Doing this isn’t as hard as it may seem. The secret is identifying the natural seams in the code and extracting them into testable and/or mockable objects and functions. Divide and conquer!

It’s not all or nothing.

Sometimes when you’re working with legacy code that doesn’t have unit tests, it’s easy to follow suit and not write tests yourself. Just because tests don’t exist for existing code doesn’t mean that you can’t write tests for your changes, though. If you write a test to confirm a change that you make, you’re future-proofing your change. If somebody comes along later and messes up your change, your test will fail even if it’s the only test in the whole world.

It’s been said before, but it’s true: one test is better than no tests. It’s also unlikely that you’ll ever go back and unit test everything in a project hat wasn’t tested previously, so just start already!

Test what makes sense.

Code coverage is great, and 100% is a great goal to strive for, but I don’t think it’s realistic in most situations. If you’re writing a test where you’re replicating the entire contents of the function you’re testing to create expectations and asserts of the test, it may be a bad test for two reasons. First, you don’t feel good about the test you’ve written. Second, you’ve made your code more rigid because changing the actual function will require you to make the same change again in the unit test. Blech!

Instead, strive to write tests that you believe are meaningful and useful. A good example of this would be translating a person object. It may not be useful to test that ObjectA.LastName equals ObjectB.LastName and ObjectA.FirstName equals ObjectB.FirstName, but it may be worthwhile to write a test that verifies that ObjectA.SsnAsInteger populates correctly into ObjectB.SsnFormattedString. It’s hard to come up with a good, brief example of this, but what I’m trying to get at is that you shouldn’t spend hours and hours working on tests that you yourself see no value in. Grab a peer and look at it together. Maybe they can help you see the value or come up with a better way to test. Or maybe you’ll both agree that the code in question simply doesn’t need to be tested.

Don’t write random value generators and object populators.

I’ve gone through this phase, and I’ve seen others go through it. I want to save you, though. Don’t do this. I know that it seems like a good idea. This should work for any string of any length, so I’ll just write a function to populate my object with a random string of random length! The problem is that when this test fails randomly 1 out of 50 test runs, you may not be able to re-create the situation. I believe it’s better to write a specific test for your specific situation. If you need to test multiple scenarios, write multiples tests.

One of my least favorite unit testing experiences comes from working with a project whose unit tests were written by a code generator that randomly populated complex source business objects, manipulated them, and then used comparison-via-reflection to verify correctness. The problem is that these tests were nearly impossible to maintain and troubleshoot when they failed.