It's well established that unit testing improves the quality and maintainability of the code that your write. Proper unit testing requires each unit test to be atomic, independent and deterministic. Ideally, each unit test should be independent of any other unit test, leave the system in the same state it was in before the test, and be able to be run repeatedly from any development workstation or build server and reliably produce the same result.

Building unit tests for methods that rely on external services is difficult, because those services are often non-deterministic. In other words, the results may differ from run to run based on the state of the service being consumed. The data in a database might change, the output of the service might change based on date or time, any number of things can vary making the test results annoyingly inconsistent.

Fortunately, a technique has emerged that allows us to write unit tests that are completely independent of non-deterministic external services. Called mock objects, this technique allows you to replace the real service with a simulated one that produces predetermined responses to expected method calls. For more information on mock objects, see this article.

Team Foundation Server, the hub of Microsoft's Application Lifecycle Management solution, offers a rich palette of mechanisms to customize and extend it to the specific needs of each software development organization. Using the Team Foundation Server SDK, you can create custom applications that respond to and integrate with work item tracking, version control, and automated build. The Team Foundation SDK includes the Team System API, which exposes much of the functionality of Team Foundation Server as an object model that’s relatively easy to use.

Many of the commonly used classes in the Team Foundation API are implemented as sealed classes. Unfortunately, none of the open source mocking frameworks can mock sealed classes. As a result, your ability to do proper mocking of TFS classes is severely limited.

This project overcomes that limitation by providing an interface and adapter for each of the commonly used sealed classes in the Team Foundation API. By using these interfaces and adapters in your TFS customization project, you can also fully mock the Team Foundation API in your unit tests. Each interface is identical to the corresponding sealed class in the Team Foundation API, with the exception that interfaces have been substituted for all the properties, method parameters and return values that otherwise use an instance of a sealed class. Each adapter is nothing more than a simple wrapper around the sealed class, where sets, gets, method calls and events are passed directly to the wrapped object.

The code in the download section of this CodePlex project includes an example showing you how to use the Team Foundation Adapters in your own customization project.

Last edited Mar 9, 2009 at 9:04 PM by mdanner, version 3


No comments yet.