So, be honest, when you hear someone talk about unit testing … what is your first thought?

• Is it: “I just don’t have the time to do unit testing”!
• Or “Our management will never approve the time for unit testing”?
• Or something similar?

Let’s look at what unit testing can do for you:

Save you Time

Yes, that’s right!

Throughout my career as a software developer, I have seen how much time unit tests can save.

Let’s think about this …

• Any developer that has written more than a few lines of code knows that it needs to be run to verify that it operates as expected. Right?
• You need to execute the feature to confirm that it takes appropriate inputs and produces appropriate outputs. You may need to go through this process several times.
• And as you build more features, it requires more effort to manually test it.
• For example, say you write a pedometer application that takes in a step count goal and an actual step count and then calculates the percent of goal you have reached.
  • To test the pedometer feature you need to execute the application, navigate to the appropriate feature, enter all of the required data, and then validate the results.
  • And if you find a bug you may have to repeat this process again, and again, and again.
  • For the feature you are working on now, how many times have you run the application to try it out? 10? 20? more?
• The idea of an automated code test is that you can write code to perform that testing.
• So if you want to test that the pedometer calculation is correct, you write an automated code test that defines appropriate inputs, calls the function under test, and verifies the results.
• Then when the users want a change to that code (and you know that they will), you can make the change and just re-run the tests.
• No need to slog through the UI again for each possible set of inputs.

This can save you LOTS of time.

Help you Find Bugs Faster

You just received a bug report. Something in the code does not work.

Instead of trying to reproduce the problem by wading through a bunch of UI, you can instead use your unit tests to quickly reproduce, find, and fix the error.

Allow you to Refactor Safely

So you are working on some code that is just too painful to deal with.

You’d like to apply some refactoring techniques to make the code cleaner and easier to use.

With no tests, you are running a risk of introducing bugs if you rework the code.

If you have unit tests in place, you can safely perform a refactoring because when you are done with the refactoring, you can rerun the tests to confirm that all is well.

Readily Add Features

You can add new features and rerun all of the existing tests to ensure that the new feature does not adversely impact any existing features.

No more worry that adding feature b will adversely affect feature a.

Minimize Those Annoying Interruptions

So you are in the middle of coding the next feature and you have to drop everything because someone entered something bad somewhere in your application and now it is crashing.

Bummer!

Having a good set of unit tests can minimize those annoying interruptions.

Enhance your Value

Don’t you just hate it when the “QA” person emails you to let you know your code doesn’t work?

This is especially difficult if that “QA” person if your boss or your client.

Having a good set of unit tests can make you look like a coding master!

Or what if the person after you changes something and now it looks like your code doesn’t work.

Unit tests help the developers that come after you to better understand and modify your code. They can re-run the tests to ensure the code still works after their changes.

Having a good set of unit tests verifies that your code works over the lifetime of the application.

Conclusion

Writing unit tests isn’t hard or time consuming once you get into the habit. And these benefits look pretty good!

For a gentle introduction to automated code testing, see my Pluralsight course: “Defensive Coding in C#”.

Enjoy!

Check out my Pluralsight courses!

I’ve heard it said that the top three techniques for improving code quality are:

• Unit testing
• Unit testing
• Unit testing

There is no better defense for the quality of your code than a set of automated code tests.

Automated code testing involves exercising code and testing its behavior by writing more code. So you have a set of code that tests your original code.

The goal of unit testing is to isolate each unit of code in an application and verify that the unit of code behaves as expected in both valid and invalid conditions.

To achieve this goal, we can:

• Refactor our code where necessary into individual units (methods) that can be tested.
• Create a set of tests for each method.
  • Tests with valid inputs.
  • Tests with invalid inputs.
  • Tests that could produce exceptions.
• Execute those tests using a testing framework, such as MSTest or NUnit, both of which are executable from with Visual Studio (ALL editions, including the free Express edition!)

Don’t have time to test? See this post!

For a gentle introduction to automated code testing, see my Pluralsight course: “Defensive Coding in C#”.

This is what one reviewer said about the “Automated Code Testing” module of this course:

This module is an excellent introduction to unit testing with C#!

In fact it should be recommended to C# subscribers as the first place to go to learn about unit testing, before they take any of the .NET unit testing courses in the library. For many this is all they will need,

It takes a viewer on a clear path from zero-knowledge about unit testing to being able to doing useful, real development, unit testing in 45 minutes.

It does a very good job of covering both the mechanics and how to make practical use unit testing.

Enjoy!

Check out my Pluralsight courses!

From Wikipedia (as of 4/14/14):

… an approach to improve software and source code, in terms of:

• General quality – Reducing the number of software bugs and problems.

• Making the source code comprehensible – the source code should be readable and understandable so it is approved in a code audit.

• Making the software behave in a predictable manner despite unexpected inputs or user actions.

Let’s consider each of these bullet points…

General quality

Coding defensively means to actively code to reduce bugs. One of the key techniques for improving quality is through automated code testing.

Don’t know that you have time in your project schedule for automated code testing? That’s a topic for another blog post. Or check out my “Defensive Coding” course referenced at the bottom of this post for a demonstration of some simple automated code testing techniques and a discussion of the “no time for testing” issue.

Comprehensible

It is not just computers that need to read and understand your code … people need to read and understand it as well.

If another developer doesn’t understand your intent, they may make incorrect assumptions about that code and make inappropriate code changes … causing your code to fail.

Plus if the code is easy to read and understand, it will be easier and less time consuming to modify as the application is maintained or enhanced over time.

The key to making source code more readable and understandable is by building “Clean Code”. The concept of “Clean Code” was first presented by Robert Martin in his book: “Clean Code: A Handbook of Agile Software Craftsmanship”.

The cleaner your code is, the easier it is to understand, maintain, and test.

Predictable

Predictable code should handle unexpected inputs or user actions by anticipating them and responding accordingly.

This includes techniques such as guard clauses, validation, and error handlers.

Putting these three concepts into a picture summarizes the goals of defensive coding:

For more information on Defensive Coding, see my Pluralsight course: “Defensive Coding in C#”.

Enjoy!

Check out my Pluralsight courses!

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!

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:

• Layout of Test Explorer in Visual Studio 2012
• Searching and Grouping in VS 2012 Test Explorer
• 101 Ways to Run Tests with Visual Studio 2012
• Running your Unit Tests Continuously

Enjoy!

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!

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.

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!

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!

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!