And I want to underscore that almost anything you could for device development in Visual Studio 2005 you can continue to do in Visual Studio 2008.

Unit Testing for Device Developers
Let's start with the one of the most significant enhancements that we added to Visual Studio 2008 - the ability to write unit tests for your VB and C# device applications. While keeping device developers' unique needs in mind, we also kept parity with how this feature works on the desktop and Web so you can simply translate what you learned around writing unit testing for devices. Of course there are subtle differences that we had to allow for but you'll clearly see familiar dialogs and experiences when creating and running unit testing for devices such as integrating test results with back-end systems like Team Foundation Server.

To demonstrate writing a simple unit test for a device class library that you created, here's what you'd have to do (See Figure 1). Let's say you have a class library written in C# that has a method that returns the bigger of the two numbers passed to it. You want to write a unit test for it and make sure you don't goof up on the logic. So once you're in that project, right-click anywhere in the editor and select "Create a new Unit Test."

If you noticed that there's a flaw in the code trust me that's intentional. I'll be using that to highlight how your unit test will help you catch these kinds of mistakes. So please ignore that for the moment and assume that this code works as you expected.

Now, once you've clicked on create unit test, the next dialog lets you pick the methods for which you want to create unit tests (See Figure 2.)

For now we'll stick with the default and click OK and provide a project Name. This will create and add a Test Project to our solution and in the process Generate the Test Methods, add references as needed, ensure that Test Configuration Files are created and then you're ready to write your unit tests and execute them.

You'll find in your test project a Method called FindBigTest() that has a stub for the unit test for our simple method and looks like this:

TestMethod()]
public void FindBigTest()
{
      Class1 target = new Class1(); // TODO: Initialize to an appropriate value
      int Number1 = 0; // TODO: Initialize to an appropriate value
      int Number2 = 0; // TODO: Initialize to an appropriate value
      int expected = 0; // TODO: Initialize to an appropriate value
      int actual;
      actual = target.FindBig(Number1, Number2);
      Assert.AreEqual(expected, actual);
      Assert.Inconclusive("Verify the correctness of this test method.");
}

Let's modify this code to add the appropriate values for Number1, Number2, and the expected Values. For example, if Number1 is 5 and Number2 is 4 then the return value should be 5. We'll also remove the Assert.Inconclusive line and once our edits are done, right-click and select "Run Tests" from the menu. If prompted you can then select either a real device or an emulator to run your unit test on.

One tip: Make sure you have .NET Compact Framework 2.0 (or higher) on the device or emulator on which unit tests are going to execute because the unit test project won't deploy .NET Compact Framework and expects it to be there already. One easy way to do this is by deploying a simple VB or C# project to the device before you run your unit tests.

[TestMethod()] //After the changes are made
public void FindBigTest()
{
    Class1 target = new Class1();
      int Number1 = 5;
      int Number2 = 4;
      int expected = 5;
      int actual;
      actual = target.FindBig(Number1, Number2);
      Assert.AreEqual(expected, actual);
}

Once you select Run tests, you'll notice that the emulator shows up (if running on the emulator) and Visual Studio starts to deploy the Unit Test Harness, your class library, and the test code to it. You'll also see that the Test Results Window shows up with the executing test reflecting the state of Pending. Give it a few seconds to execute and you should see something similar to Figure 3.

That clearly worked when Number1 was greater than Number2. Now let's test the other condition as well and make sure that if Number2 in bigger then our code works also as expected and returns that. So in our test we can swap Number1=4 and Number2=5 and execute the test again. Now it gets interesting. Your test just failed (see Figure 4).

No, don't panic. Remember the flaw in the code before? We were returning Number1 in both cases. While we did it intentionally to highlight how unit testing work, these are the kinds of scenarios that having unit tests can save you hours of debugging. So to ensure that this example works, simply fix the code in the class to return Number2 where applicable, rerun your unit test, and it will certainly come back as Passed.