All .NET unit testing frameworks have similar parts and style of testing This tutorial explores the anatomy of a typical unit test framework. Then it delves into the architecture of the simple sample framework built during the course.
- [Voiceover] In this video, I'll look at the anatomy of a unit test framework, how test projects are configured, and take a quick look at my implementation of a test framework. On the screen is a representation of my brokerage code library. I need to test some of the class methods in this library. When it's time to write the test, I have to decide where to put the test code. In .Net, you can put the test code in the BrokerageLib. There are no rules that prevent you from locating the tests there. The downside to the approach is that the test code is deployed with the library, not an ideal choice for production-ready code.
Instead, it's more common to create a separate code library that contains all the test code. The test library needs a reference to the BrokerageLib so that the test code can instantiate the classes and call the methods. In tester lingo, the BrokerageLib is known as the System under test and you'll occasionally see the acronym SUT used. For example, I commonly add a using statement to my TestLib aliasing SUT to the root name space like this, using SUT equal BrokerageLib.
The TestLib also has a reference to a unit test framework. This test framework provides a selection of types and methods that simplify writing test code. In this example, I've added a reference to xUnit which provides assertion methods, a set of attributes that use reflection to find which test methods to run in the test library, and it also generates a list of pass/fail test results whenever the tests are run. There are many .Net friendly testing frameworks. In this example, I've swapped out xUnit for MSTest. But, as you can see, it contains similar testing tools.
Choosing the framework is matter of personal choice, which one fits your view of how a unit test framework should run or which one provides the most complete set of testing tools for your scenario. Finally, I need a test runner, the app that is responsible for running the tests and showing the results. To review what we have on the screen, we're responsible for creating the application code in BrokerageLib and the test code in TestLib. Someone else creates the unit test library and the test runner. We're leveraging them to automate our tests.
In Visual Studio, the test runner is built into the IDE. There is also a command line version and Microsoft provides a test runner with Visual Studio Team Services for running tasks on a remote team server. Here's a question I hear when talking about unit tests, "How does the test runner know what methods "to call in the test library?" Most test frameworks have a way to mark the methods that contain the test code. TestRunner examines all the classes in the test project and finds the designated test methods, runs the methods, gathers the results, and outputs the results so we can verify that the tests pass, or drill deeper to see which tests failed.
During the rest of this chapter, I'll create a simple version of a unit testing framework. Here is how it's designed. I have the BrokerageLib project. It already contains the business code. I'll create a TestLib project and add the test methods. This will be another C# class library. To keep it simple, instead of creating a separate unit test framework, I'll add the unit testing helpers to the TestLib project. Finally, I'll add a WPF project to the solution. This will be the test runner. It'll have a button for running the tests, and a data grid for showing the results.
- Examining types of frameworks
- Choosing a naming convention
- Creating unit tests
- Running unit tests with Visual Studio
- Modifying and correcting code
- Handling exceptions
- Installing and using nUnit
- Viewing test results with CodeLens