Deborah's Developer MindScape : VB, Testing

Running Your Unit Tests Continuously

Deborah Kurata — Wed, 26 Sep 2012 23:56:45 GMT

One of the new unit testing features in VS 2012 (Premium or Ultimate) is the continuous test runner. When turned on, it automatically executes your unit tests after every successful build.

Digressing a moment … in the early 1990's Shari Lewis and Lamb Chop would sing a version of "The Song that Never Ends" at the end of each episode of their show. In memory of Lamb Chop:

It is the test that never ends.
It goes on and on my friends.
Someone starting running it not knowing what it was,
and they'll continue running it forever just because… <repeat>

To turn on the continuous test runner, select the icon in the upper left corner of the Test Explorer:

The tests will automatically execute asynchronously after each build. They also automatically run when first opening a solution containing the tests.

NOTE: The tests are not executed after a build that is part of a Start With Debugging (F5) or Start Without Debugging operation.

Any failed tests from previous runs are executed first. If they pass, the other (previously passed) tests are executed. If they fail, the other (previously passed) tests are not executed.

This last point has caused me problems. I made a change that would have caused a previously passed tests to fail but I was not notified because I have some other failing tests. I had to manually run the tests in order for the previously passed tests to fail appropriately.

Use the search feature of Test Explorer (detailed in this prior post) to filter the list of tests to execute.

Enjoy!

Test Explorer in Visual Studio 2012

Deborah Kurata — Mon, 17 Sep 2012 00:30:02 GMT

One of the new things about testing in Visual Studio 2012 is that it is now available in *all* editions of Visual Studio all the way to Visual Studio Express!

The Test Explorer in Visual Studio 2012 replaces the Test View window in Visual Studio 2010. The following posts outline the Test Explorer features:

Enjoy!

101 Ways to Run Tests with Visual Studio 2012

Deborah Kurata — Sun, 16 Sep 2012 20:59:09 GMT

OK 101 is an exaggeration, but there are many ways to run your tests in Visual Studio 2012.

From the test code file

While you are writing or editing a test method, you can right click anywhere within the method and run or debug the test.

[Red rectangle added for illustration.]

All of the tests in Test Explorer are displayed "grayed out" except for the executed test as shown below. Click on the test to view the result details in the right pane (or bottom pane if your Test Explorer is sized to display vertically).

From the code editor, you can also run all of the tests within a code file by right-clicking anywhere within the code file, but outside of a specific method. Clicking in an empty space between two methods, for example, will execute all of the tests in the code file.

From Test Explorer Toolbar

View the Test Explorer window using Test | Windows | Test Explorer. The Test Explorer window toolbar provides many ways to run your tests.

Run All
Runs all of the tests displayed in Test Explorer. If the list of tests are filtered by search criteria, only the filtered tests are executed. (See this prior blog post for information on searching within Test Explorer.)
Run Failed Tests
Runs only the failed tests displayed in Test Explorer.
Run Not Run Tests
Only runs the tests displayed in Test Explorer which were not previously run since opening Visual Studio.
Run Passed Tests
Runs only the passed tests displayed in Test Explorer.
Repeat Last Run
Runs the prior test run again, but only on the files displayed in Test Explorer. If you Run All then filter the tests in Test Explorer then Repeat Last Run, only the filtered tests will be executed again.

From Test Explorer Context Menu

Right-clicking on a test in Test Explorer provides run options.

You can select a single test, multiple tests using the Ctrl and Shift keys, or all tests using the Select All option from the context menu. Then you can Run or Debug the selected tests.

Use these techniques to run only the tests you are interested in.

Enjoy!

Searching and Grouping in VS 2012 Test Explorer

Deborah Kurata — Sun, 16 Sep 2012 19:59:50 GMT

Visual Studio 2012 Test Explorer has extensive searching and limited grouping capabilities. (Visual Studio 2010's Test View window had more grouping options by way of its many sorting parameters.)

Searching

Entering text into the Test Explorer Search box filters the list of tests to those containing the entered text. In the example below, entering "customer" in the search box filters the list to all test names containing "customer".

By default, the search matches within the test name, but there are other choices. To view the other options, click the down arrow to the right of the Search box in the toolbar as shown below. Even though it looks a little like one large option name, these are actually three options:

Test File Path
Fully Qualified Name
Test Result

Select one of these options, then type the search parameter within the provided quotation marks. Press the Enter key to execute the search.

Test File Path searches the paths to the test code files. In this example, the tests are in two components in two different directories:

C:\Users\Deborah\Speaking\Other\AcmeCustomerManagement_BestKeptSecrets_2012\ACM.LibraryCSharpTest
C:\Users\Deborah\Speaking\Other\AcmeCustomerManagement_BestKeptSecrets_2012\ACM.BLCSharpTest

The above example finds all of the tests in the LibraryCSharpTest component.

Fully Qualified Name searches the path and file name.

Test Result has several valid search parameters: "Not Run", "Skipped", "Passed" or "Failed". These options filter the list to defined test outcome.

Grouping

By default, the Test Explorer groups the tests by test outcome as shown in the prior screen shots. The only other group-by option is by duration. This groups by the time it took to execute the test.

Use these techniques to filter and group the tests in the Test Explorer window.

Enjoy!

EDITED 9/28/12 to correct typographical errors.

Layout of Test Explorer in Visual Studio 2012

Deborah Kurata — Sun, 16 Sep 2012 01:18:47 GMT

In Visual Studio 2012, the Visual Studio 2010 Test View window has been replaced by a new Test Explorer window.

By default, it appears on the left side of the Visual Studio Interactive Development Environment (IDE) as shown below:

(Red box added for illustration)

When you run the unit tests, the result appears in the bottom panel of the Test Explorer window:

Since many unit tests may have the same prefix and a long and descriptive name, docking the Test Explorer on the left often cuts off the unique portions of the names. Instead of making the window wider, consider moving it to the bottom:

(Red box added for illustration)

The test results now appear in the right panel of the Test Explorer window:

Moving the Test Explorer window from the left side to the bottom gives you more horizontal space to view the tests and their execution times. It also gives you more space to view the test results.

Enjoy!

VS 2010: Test View Error

Deborah Kurata — Thu, 22 Apr 2010 04:01:49 GMT

I was working on an application in Visual Studio 2010 today, opened the Test View window and got an exception as shown below.

Here is the first part of the error in text: "An exception was encountered while constructing the content of this frame..."

With the help of Chuck Sterling, I got an answer on how to fix the problem. It is detailed here:

http://blogs.msdn.com/charles_sterling/archive/2010/04/21/test-view-issue-an-exception-was-encountered-while-constructing-the-content-of-this-frame.aspx

Thanks Chuck!

Enjoy!

Unit Testing: Exposing Private Members

Deborah Kurata — Thu, 29 Oct 2009 23:19:53 GMT

Visual Studio 2008 (Professional Edition and above) provides a really nice set of tools for development and execution of unit tests. It is, of course, easy for your tests to access the public properties and methods of your classes. But what about those private members?

[To begin with an overview of unit testing, start here.]

[To expose internal (C#) or friend (VB) members, see this post.]

You may have properties or methods in your class defined to be private. This post details how to test those methods using the unit testing features in Visual Studio.

NOTE: There are some testing philosophies that recommend you never test your private members; rather you test the public/internal/friend members and assume that those will provide coverage for all of your private members as well. Regardless of your point of view on this topic, this post provides the how-to so you can decide for yourself whether you want to or not.

Let's say your Customer class has a CustomerId property that looks like this:

In C#:

private int? _CustomerId;
public int? CustomerId
{
    get { return _CustomerId; }
    private set
    {
        if (_CustomerId == null || !_CustomerId.Equals(value))
        {
            string propertyName = "CustomerId";
            if (!_CustomerId.Equals(value))
            {
                _CustomerId = value;
            }
        }
    }
}

In VB:

Private _CustomerId As Integer?
Public Property CustomerId() As Integer?
    Get
        Return _CustomerId
    End Get
    Private Set(ByVal value As Integer?)
        If _CustomerId Is Nothing OrElse _
                      Not _CustomerId.Equals(value) Then
            Dim propertyName As String = "CustomerId"
            If Not _CustomerId.Equals(value) Then
                _CustomerId = value
            End If
        End If
    End Set
End Property

Notice in both cases, the setter is private. The expectation is that the business object will set this value. However, you can you unit test it if you cannot set it?

The answer is PrivateObject.

PrivateObject is a class that allows test code to call class members that are not public. You PrivateObject to access private members of your class in your unit tests.

NOTE: You can also use PrivateObject for other non-public class members.

The following demonstrates how to use PrivateObject.

In C#:

/// <summary>
///A test for CustomerId
///</summary>
[TestMethod()]
public void CustomerIdTest()
{
    Customer target;
    int? expected;
    int? actual;

    // Null to Value
    target = new Customer();
    expected = 42;

    PrivateObject po = new PrivateObject(target);
    po.SetProperty("CustomerId", expected);
    actual = target.CustomerId;
    Assert.AreEqual(expected, actual, "Values are not equal");
}

In VB:

'''<summary>
'''A test for CustomerId
'''</summary>
<TestMethod()> _
Public Sub CustomerIdTest()
    Dim target As Customer
    Dim expected As Integer?
    Dim actual As Integer?

    ' Null to value
    target = New Customer
    expected = 42

    Dim po As PrivateObject = New PrivateObject(target)
    po.SetProperty("CustomerId", expected)
    actual = target.CustomerId
    Assert.AreEqual(expected, actual, "Values are not equal")
End Sub

NOTE: This is only part of the code you would need to fully test the CustomerId property. Only one testing scenario was covered to instead focus on the PrivateObject syntax.

The code creates a new instance of PrivateObject, passing the instance of the class that has the private member you wish to access.

PrivateObject has methods such as GetProperty, SetProperty, GetField, SetField, and Invoke. These methods provide access to the private or other non-public members of your class.

Use PrivateObject whenever you need to access a private member in your class from your unit testing code.

Enjoy!

Unit Testing: Exposing Internal/Friend Members

Deborah Kurata — Thu, 29 Oct 2009 22:23:55 GMT

[To begin with an overview of unit testing, start here.]

[To expose private members, see this post.]

You may have properties or methods in your class defined to be internal (C#) or friend (VB). This post details how to test those methods using the unit testing features in Visual Studio.

Well, it is easy. You just need to use this line of code:

In C#:

[assembly: InternalsVisibleTo("BoTest")]

In VB:

<Assembly: InternalsVisibleTo("BoTest")>

Where BoTest is the name of your unit testing project.

The hard part is finding where you put this line of code. It should reside in your AssemblyInfo file.

This file is relatively easy to find in your C# project; not so easy to find in your VB project. Here are the steps for both.

In C#:

Find the project you want to test in Solution Explorer.
Open the Properties node.
Double-click on the AssemblyInfo.cs file.
Set the InternalsVisibleTo attribute into the AssemblyInfo.cs file.
Rebuild the project.

In VB:

Find the project you want to test in Solution Explorer.
Click on the Show All Files button in the Solution Explorer toolbar.
Open the My Project node
Double-click on the AssemblyInfo.vb file.
Set the InternalsVisibleTo attribute into the AssemblyInfo.vb file.

Use this technique whenever you have internal/friend members in a class that you wish to access with your unit testing code.

Enjoy!

Unit Testing: Testing Properties

Deborah Kurata — Thu, 29 Oct 2009 22:01:14 GMT

Visual Studio 2008 (Professional Edition and above) provides a really nice set of tools for development and execution of unit tests. This post provides suggestions for testing your property getters and setters.

[To begin with an overview of unit testing, start here.]

Let's say your Customer class has a LastName property that looks like this:

In C#:

    private string _LastName;
    public string LastName
    {
        get { return _LastName; }
        set
        {
            if (_LastName == null || _LastName != value)
            {
                string propertyName = "LastName";
                // Perform any validation here
                if (_LastName != value)
                {
                    _LastName = value;
                    SetEntityState(EntityStateType.Modified,
                                               propertyName);
                }
            }
        }
    }

(Someone just mentioned how all of those ending braces look like a flock of sea gulls! LOL!)

In VB:

    Private _LastName As String
    Public Property LastName() As String
        Get
            Return _LastName
        End Get
        Set(ByVal value As String)
            If _LastName Is Nothing OrElse _
                                 _LastName IsNot value Then
                Dim propertyName As String = "LastName"
                ' Perform any validation
                If _LastName IsNot value Then
                    _LastName = value
                    SetEntityState(EntityStateType.Modified, _
                                                  propertyName)
                End If
            End If
        End Set
    End Property

NOTE: The SetEntityState method used in this code is coming from the business object base class provided in this prior post.

The key step for developing a good unit test is to define the test scenarios.

Looking at the requirements, the following testing scenarios are required for the LastName property:

Initial null value; set to null value (should perform validation but not set the dirty flag)
Initial null value; set to valid string (should perform validation and set the dirty flag)
Initial null value; set to empty string (should perform validation and set the dirty flag)
Initial string value; set to null value (should perform validation and set the dirty flag)
Initial string value, set to different string value (should perform validation and set the dirty flag)
Initial string value, set to same string value (should not perform validation and not set the dirty flag)
Initial string value, set to empty value (should perform validation and set the dirty flag)

And if you have validation code, you will have more scenarios to test valid and invalid values. But this is enough to give you the general idea.

If you are building the unit test from existing code, you can generate the basic structure of the unit test for the property following the techniques detailed in this prior post.

But the test generation only gives you the basic template for testing your properties. This post focuses on how to update that template to perform the required unit testing.

Visual Studio will generate the following unit test template for the LastName property that was shown at the beginning of this post:

In C#:

/// <summary>
///A test for LastName
///</summary>
[TestMethod()]
public void LastNameTest()
{
    Customer target = new Customer(); // TODO: Initialize to an appropriate value
    string expected = string.Empty; // TODO: Initialize to an appropriate value
    string actual;
    target.LastName = expected;
    actual = target.LastName;
    Assert.AreEqual(expected, actual);
    Assert.Inconclusive("Verify the correctness of this test method.");
}

In VB:

'''<summary>
'''A test for LastName
'''</summary>
<TestMethod()> _
Public Sub LastNameTest()
    Dim target As Customer = New Customer ' TODO: Initialize to an appropriate value
    Dim expected As String = String.Empty ' TODO: Initialize to an appropriate value
    Dim actual As String
    target.LastName = expected
    actual = target.LastName
    Assert.AreEqual(expected, actual)
    Assert.Inconclusive("Verify the correctness of this test method.")
End Sub

To cover the defined testing scenarios, this code needs to be enhanced as follows:

In C#:

/// <summary>
///A test for LastName
///</summary>
[TestMethod()]
public void LastNameTest()
{
    Customer target;
    string expected;
    string actual;

     // Null to Null
    target = new Customer();
    expected = null;
    target.LastName = expected;
    actual = target.LastName;
    Assert.AreEqual(expected, actual, "Values are not equal");
    Assert.AreEqual(false, target.IsDirty,
                               "Object not marked as dirty");

    // Null to value
    target = new Customer();
    expected = "Johnson";
    target.LastName = expected;
    actual = target.LastName;
    Assert.AreEqual(expected, actual, "Values are not equal");
    Assert.AreEqual(true, target.IsDirty, _
                                "Object not marked as dirty");

    // Null to Empty
    target = new Customer();
    expected = string.Empty;
    target.LastName = expected;
    actual = target.LastName;
    Assert.AreEqual(expected, actual, "Values are not equal");
    Assert.AreEqual(true, target.IsDirty,
                                "Object not marked as dirty");

    // Value to Null
    target = new Customer() {LastName = "Johnson"};
    target.SetEntityState(BoBase.EntityStateType.Unchanged);
    expected = null;
    target.LastName = expected;
    actual = target.LastName;
    Assert.AreEqual(expected, actual, "Values are not equal");
    Assert.AreEqual(true, target.IsDirty,
                                "Object not marked as dirty");

    // Value to new Value
    target = new Customer() {LastName = "Johnson"};
    target.SetEntityState(BoBase.EntityStateType.Unchanged);
    expected = "Jones";
    target.LastName = expected;
    actual = target.LastName;
    Assert.AreEqual(expected, actual, "Values are not equal");
    Assert.AreEqual(true, target.IsDirty,
                                "Object not marked as dirty");

    // Value to same Value
    target = new Customer() {LastName = "Johnson"};
    target.SetEntityState(BoBase.EntityStateType.Unchanged);
    expected = "Johnson";
    target.LastName = expected;
    actual = target.LastName;
    Assert.AreEqual(expected, actual, "Values are not equal");
    Assert.AreEqual(false, target.IsDirty,
                                "Object not marked as dirty");

    // Value to Empty
    target = new Customer() {LastName = "Johnson"};
    target.SetEntityState(BoBase.EntityStateType.Unchanged);
    expected = string.Empty;
    target.LastName = expected;
    actual = target.LastName;
    Assert.AreEqual(expected, actual, "Values are not equal");
    Assert.AreEqual(true, target.IsDirty,
                                "Object not marked as dirty");
}

In VB:

'''<summary>
'''A test for LastName
'''</summary>
<TestMethod()> _
Public Sub LastNameTest()
    Dim target As Customer
    Dim expected As String
    Dim actual As String

    ' Null to Null
    target = New Customer
    expected = Nothing
    target.LastName = expected
    actual = target.LastName
    Assert.AreEqual(expected, actual, "Values are not equal")
    Assert.AreEqual(False, target.IsDirty, _
                                "Object not marked as dirty")

    ' Null to value
    target = New Customer
    expected = "Johnson"
    target.LastName = expected
    actual = target.LastName
    Assert.AreEqual(expected, actual, "Values are not equal")
    Assert.AreEqual(True, target.IsDirty, _
                                "Object not marked as dirty")

    ' Null to Empty
    target = New Customer
    expected = String.Empty
    target.LastName = expected
    actual = target.LastName
    Assert.AreEqual(expected, actual, "Values are not equal")
    Assert.AreEqual(True, target.IsDirty, _
                                "Object not marked as dirty")

    ' Value to Null
    target = New Customer With {.LastName = "Johnson"}
    target.SetEntityState(BOBase.EntityStateType.Unchanged)
    expected = Nothing
    target.LastName = expected
    actual = target.LastName
    Assert.AreEqual(expected, actual, "Values are not equal")
    Assert.AreEqual(True, target.IsDirty, _
                                "Object not marked as dirty")

    ' Value to new Value
    target = New Customer With {.LastName = "Johnson"}
    target.SetEntityState(BOBase.EntityStateType.Unchanged)
    expected = "Jones"
    target.LastName = expected
    actual = target.LastName
    Assert.AreEqual(expected, actual, "Values are not equal")
    Assert.AreEqual(True, target.IsDirty, _
                                "Object not marked as dirty")

    ' Value to same Value
    target = New Customer With {.LastName = "Johnson"}
    target.SetEntityState(BOBase.EntityStateType.Unchanged)
    expected = "Johnson"
    target.LastName = expected
    actual = target.LastName
    Assert.AreEqual(expected, actual, "Values are not equal")
    Assert.AreEqual(False, target.IsDirty, _
                               "Object not marked as dirty")

    ' Value to Empty
    target = New Customer With {.LastName = "Johnson"}
    expected = String.Empty
    target.LastName = expected
    actual = target.LastName
    Assert.AreEqual(expected, actual, "Values are not equal")
    Assert.AreEqual(True, target.IsDirty, _
                                "Object not marked as dirty")
End Sub

NOTE: The SetEntityState method and IsDirty property used in this code are coming from the business object base class provided in this prior post.

NOTE: You may get an error when calling SetEntityState because in the business object base class is defined to be protected internal (protected friend in VB), not public. If so, you need to use the technique presented here to allow your tests to access internal/friend properties and methods.

WOW! That is a LOT of test code! Some experts have said that every line of code needs at least 3 - 5 lines of test code.

We have 17 lines of C# code and 15 lines of VB code in our property procedure. If I counted correctly, there are 51 lines of C# test code and 50 lines of VB test code. So that is about 3x the number of code lines.

Let's walk through what this test code is doing, following through with the testing scenarios provided earlier in this post.

Scenario 1: The code creates a new instance of the Customer class. By default, a new instance sets any string values to null/nothing. So the test code simply sets the property to null/nothing, gets the value, confirms that the value is as expected, and ensures that it did not get marked as dirty.

Scenario 2: The code again creates a new instance of the Customer class. By default a new instance sets any string values to null/nothing. So the test code sets the property to a value, gets the value, confirms that the value is as expected, and ensures that the object was marked as dirty.

Scenario 3: The code again creates a new instance of the Customer class. By default a new instance sets any string values to null/nothing. So the test code sets the property to an empty string, gets the value, confirms that the value is as expected, and ensures that the object was marked as dirty.

Now for the harder scenarios. There is no easy way to set a non-null initial value for a property. One option is to set the private backing variable to the desired initial value. But with the backing variable being private, there is extra code to write to make it work.

Another option is to set the property using the setter. But this marks the object as dirty, adversely interfering with the test. So if you use this technique, you then need to call SetEntityState to clear the entity state and ensure it is not marked as dirty. The sample code used this technique.

Scenario 4: The code creates a new instance of the customer class, setting the initial value of the property to a valid value. It then calls SetEntityState to clear the dirty flag. Then the test code sets the property to a null, gets the value, confirms that the value is as expected, and ensures that the object was marked as dirty.

Scenario 5: The code creates a new instance of the customer class, setting the initial value of the property to a valid value. It then calls SetEntityState to clear the dirty flag. Then the test code sets the property to another valid value, gets the value, confirms that the value is as expected, and ensures that the object was marked as dirty.

Scenario 6: The code creates a new instance of the customer class, setting the initial value of the property to a valid value. It then calls SetEntityState to clear the dirty flag. Then the test code sets the property to the same value, gets the value, confirms that the value is as expected, and ensures that the object was not marked as dirty.

Scenario 7: The code creates a new instance of the customer class, setting the initial value of the property to a valid value. It then calls SetEntityState to clear the dirty flag. Then the test code sets the property to an empty string, gets the value, confirms that the value is as expected, and ensures that the object was marked as dirty.

If the field was validated, such as required field validation or a maximum length check, additional scenarios and associated test code would be required.

So for every business object property in your application, define the appropriate set of test scenarios and build the test code to support each scenario.

Or build a test base class that performs the basic set of tests for each of your properties. But that is left for a future post.

Enjoy!

Unit Testing: Code Coverage

Deborah Kurata — Sun, 25 Oct 2009 23:27:00 GMT

Visual Studio 2008 (Team System ONLY) provides a really nice set of tools for viewing the code coverage of your unit tests.

NOTE: While Visual Studio 2008 Professional Edition has tools for building, executing, and debugging unit tests, it does NOT include the code coverage tools.

[To begin with an overview of unit testing, start here.]

Code coverage illustrates how much of the code was executed (or covered) by the unit tests.

NOTE: This post assumes you have already generated or created at least one unit test.

To view the code coverage for your unit tests:

1) Enable code coverage in the test run configuration file.

When you create your first unit test, Visual Studio adds a LocalTestRun.testrunconfig file to your solution under the Solution Items folder. Double-click on this file to open it:

Select Code Coverage from the left list:

Select the files on the right that you wish to view code coverage. Don't pick your test projects; rather pick the projects containing the code that is being tested. Then click Apply and Close.

2) Run your unit tests. The Test Results dialog appears.

See this prior post for more information on executing unit tests.

Your results should appear similar to the following:

3) If the tests pass, click the Show Code Coverage Results button in the far upper right corner of the Test Results dialog. The Code Coverage Results dialog appears.

This dialog displays all of the code in all of the files you selected for code coverage instrumentation. Drill down as needed to find the desired code.

In this case, the unit test is testing the getter and setter for the LastName. Notice that the covered percentage for both the getter and setter is 100%. That means that the unit test is executing every line of code in the getter and setter.

4) Double click on any item in the Code Coverage dialog to open the associated code window.

Notice how the code is color-coded. Blue shows code that was executed by the unit test. Red shows code that was not executed.

Use this feature to ensure you have unit tests for each unit of your code.

Enjoy!

EDITED 10/27/09: While Visual Studio 2008 Professional Edition has tools for building, executing, and debugging unit tests, it does NOT include the code coverage tools. In the original version of this post, I incorrectly stated that code coverage tools were available in the Professional Edition. This post has been corrected.

Unit Testing: Execution

Deborah Kurata — Sun, 25 Oct 2009 22:50:44 GMT

Visual Studio 2008 (Professional Edition and above) provides a really nice set of tools for development and execution of unit tests.

[To begin with an overview of unit testing, start here.]

This prior post demonstrates how to build a unit test using the "Create Unit Tests..." feature of the Code Editor. This post demonstrates how to execute a unit test.

NOTE: This post assumes you have already generated or created at least one unit test.

To execute one or more unit tests:

1) Open your solution in Visual Studio.

The solution should include both the project(s) to test and the test project(s).

2) Select Test | Windows | Test View from the menu to view the Test View window. This window contains every method marked with the TestMethod attribute.

The solution used for the screenshot above has two LastNameTest unit tests: One for the VB example and one for the C# example. If you coded along from the prior unit testing post, you will only have one for whichever language you selected. If you have been creating unit tests for one of your projects, you may have hundreds of tests in this list.

To execute unit tests:

1) Select one or more tests from the list of tests in the Test View window.

You can add columns and sort the list or use the filter feature to make it easier to locate and select the desired tests to execute.

2) Click the Run Selection button in the upper left corner of the Test View window or right-click on any selected test and select "Run Selection" from the context menu.

The selected test(s) will then execute, displaying their status in the Test Results window:

When the test is complete, the Test Results window will look something like this:

Both of the tests shown in the above screenshot are marked as Inconclusive because the generated unit testing code used the Assert class Inconclusive method. The generated unit testing template is designed to prevent a false positive. It generates an inconclusive result until you update the unit test with correct valid and invalid values and remove the Inconclusive method call.

To see more information on the result of the test, double-click on a test result.

To run the test again, use the Run or Debug buttons at the top of the Test Results window.

If any of the tests don't pass, they are marked as Failed in the Test Results window as shown below.

Double click on any of the failed tests to view the test results:

The Error Stack Trace at the bottom of this window gives you further information on the source of the failure. Click on any link in the stack trace to jump to the associated location in the code.

You can also debug the code as the test is executing if you "Debug Selection" option instead of the "Run Selection" option.

After you update the unit tests with valid code and the tests pass, the Test Results will appear as follows:

Notice the color-coded green passing indicator.

Enjoy!

Unit Testing: An Introduction

Deborah Kurata — Sun, 25 Oct 2009 21:04:20 GMT

If you have Visual Studio 2008 or later and have the Professional Edition or better (NOT the Express Editions), you have some very nice unit testing tools within your Visual Studio environment. These tools help you write, execute, and track your unit tests and code coverage. This post provides an introduction to using these tools.

If you are new to unit testing, the idea is to test the smallest possible units of your code. In most cases, the smallest units of code are the property procedures and methods of your classes.

For more general information about the purpose of unit testing, see this link.

NOTE: Unit testing is not meant to replace integration testing, system testing, or user testing.

In some development methodologies, such as Test Driven Development (TDD), unit tests are written before the code is written. You capture the basic requirements in the unit test and then write the code. The code is complete when the unit tests pass. Visual Studio 2010 has features to assist with this "unit test first" approach.

But this introduction demonstrates how to write unit tests for existing code. This technique is helpful if you follow a code-first approach or if you received code from another source or have old code that did not originally have unit tests.

Build the Code

The business object tested in this post is a simplified Customer class that uses the business object base class defined in this post.

The Customer class is shown below.

In C#:

public class Customer: BoBase
{
    private int? _CustomerId;
    public int? CustomerId
    {
        get { return _CustomerId; }
        internal set
        {
            if (_CustomerId == null || !_CustomerId.Equals(value))
            {
                string propertyName = "CustomerId";
                // Perform any validation here
                if (!_CustomerId.Equals(value))
                {
                    _CustomerId = value;
                    SetEntityState(EntityStateType.Modified,
                                               propertyName);
                }
            }
        }
    }

    private string _FirstName;
    public string FirstName
    {
        get { return _FirstName; }
        set
        {
            if (_FirstName == null || _FirstName != value)
            {
                string propertyName = "FirstName";
                // Perform any validation here
                if (_FirstName != value)
                {
                    _FirstName = value;
                    SetEntityState(EntityStateType.Modified,
                                               propertyName);
                }
            }
        }
    }

    private string _EmailAddress;
    public string EmailAddress
    {
        get { return _EmailAddress; }
        set
        {
            if (_EmailAddress == null || _EmailAddress != value)
            {
                string propertyName = "EmailAddress";
                // Perform any validation here
                if (_EmailAddress != value)
                {
                    _EmailAddress = value;
                    SetEntityState(EntityStateType.Modified,
                                               propertyName);
                }
            }
        }
    }
}

In VB:

Public Class Customer
Inherits BOBase

    Private _CustomerId As Integer?
    Public Property CustomerId() As Integer?
        Get
            Return _CustomerId
        End Get
        Friend Set(ByVal value As Integer?)
           If _CustomerId Is Nothing OrElse _
                    Not _CustomerId.Equals(value) Then
              Dim propertyName As String = "CustomerId"
              ' Perform any validation
              If Not _CustomerId.Equals(value) Then
                 _CustomerId = value
                 SetEntityState(EntityStateType.Modified, propertyName)
                End If
            End If
        End Set
    End Property

    Private _FirstName As String
    Public Property FirstName() As String
        Get
            Return _FirstName
        End Get
        Set(ByVal value As String)
            If _FirstName Is Nothing OrElse _
                                _FirstName IsNot value Then
                Dim propertyName As String = "FirstName"
                ' Perform any validation
                If _FirstName IsNot value Then
                    _FirstName = value
                    SetEntityState(EntityStateType.Modified, _
                                                  propertyName)
                End If
            End If
        End Set
    End Property

    Private _EmailAddress As String
    Public Property EmailAddress() As String
        Get
            Return _EmailAddress
        End Get
        Set(ByVal value As String)
            If _EmailAddress Is Nothing OrElse _
                             _EmailAddress IsNot value Then
                Dim propertyName As String = "EmailAddress"
                ' Perform any validation
                If _EmailAddress IsNot value Then
                    _EmailAddress = value
                    SetEntityState(EntityStateType.Modified, _
                                                  propertyName)
                End If
            End If
        End Set
    End Property
End Class

The first if statement in each of the property procedures for the Customer class checks whether the current value is null or was changed. If the property is changed, you want to revalidate it, set it as modified, and generate a PropertyChanged event (which is handled in the SetEntityState method).

NOTE: C# uses a != operator to judge whether the value was changed. VB cannot use the <> operator because VB propagates null values. So if either value is null (nothing) the result is false. (See this msdn entry for more information.) To prevent this problem, IsNot is used in the VB code to determine if the value was changed.

The null check allows for possible validation of required fields (that is, fields that cannot be null or empty). If you know you will never need a null validation check, you can leave the null check off the first if statement.

The propertyName variable defines a name that you can use in any validation error messages and it is the name used in the PropertyChanged event.

You can then perform any necessary validation. In this simple example, no validation was added. If you want to see an example of some validation, check out this post.

Finally, if the value was changed, the backing variable is set to the new value and the SetEntityState method is called to mark the business object as "dirty" and to generate the PropertyChanged event.

Define the Testing Scenarios

So let's start with the test of the LastName property. Looking at the requirements, the following testing scenarios are required:

Initial null value; set to null value (should perform validation but not set the dirty flag)
Initial null value; set to valid string (should perform validation and set the dirty flag)
Initial null value; set to empty string (should perform validation and set the dirty flag)
Initial string value; set to null value (should perform validation and set the dirty flag)
Initial string value, set to different string value (should perform validation and set the dirty flag)
Initial string value, set to same string value (should not perform validation and not set the dirty flag)
Initial string value, set to empty value (should perform validation and set the dirty flag)

And if you have validation code, you will have more scenarios to test valid and invalid values. But this is enough to give you the general idea.

So now let's generate the unit test for the LastName property using the tools provided in Visual Studio (Professional Edition or above).

Generate the Unit Test

The following are the steps for generating the unit test for a particular property procedure or method:

1) Open the Code Editor for the code you want to test.

2) Right-click and select Create Unit Tests... from the context menu.

The following dialog will appear:

3) Select the properties, methods, or constructors you wish to test.

If you were in a specific property procedure or method, that procedure or method is automatically checked in this dialog. You can select to generate tests for any properties, methods, or constructors using this dialog.

Notice the Output project combobox on this dialog. Using this combobox, you can create a new C# unit test, new VB unit test, or select any existing unit test project if you already have some in your solution. This allows you to add unit tests to existing unit testing projects at any point in the development process.

4) Click OK.

5) If you are creating a new C# or VB project, enter the project name and click Create.

6) The test project is then added to your Solution Explorer.

If you created a VB test project, the result is the same, but with a CustomerTest.vb file within the BoTest project.

View the Generated Code

Visual Studio automatically creates an first cut of your unit testing code.

In C#:

Double-click on CustomerTest.cs to view the code.

In VB:

Double-click on CustomerTest.vb to view the code.

The TestMethod attribute defines this method as a unit test. It is then picked up by the other unit testing tools within Visual Studio.

The generated code includes some ToDo notes, defining where you should change the code.

The Assert class is a key aspect of your unit tests. It provides many methods that you can use to assert whether your test produced expected results.

The generated code uses two of the Assert class methods. The AreEqual method determines whether the expected and actual values are equal. If not, it fails the test.

The Inconclusive method always causes the test to fail. This is added to all generated code to ensure that the test will fail until you modify the test with valid values.

At this point, you can try to execute this unit test, or update it first and then execute it.

See the following posts for more information:

Unit Testing: Execution
Unit Testing: Code Coverage (Visual Studio Team Editions ONLY)
Unit Testing: Testing Properties
Unit Testing: Exposing Internal/Friend Members
Unit Testing: Exposing Private Members

Enjoy!