The Art of Unit Testing & TDD Master Class in .NET

Roy Osherove defines a unit test and the three properties of a good one, readability, maintainability and trust, and explains why unit testing efforts fail when any of them is missing. Writing NUnit tests in Visual Studio for a calculator class, he covers three-part test names, readable inputs, factory methods instead of setup methods, and Assert.Throws instead of the ExpectedException attribute. He also separates unit from integration tests, runs tests with TestDriven.NET, and adds features test first: a failing test, the simplest passing code, then refactoring.

Roy Osherove introduces code katas for practicing TDD and starts the string calculator kata, whose Add method returns the sum of the comma-separated numbers in a string. He writes one test at a time, starting with an empty string returning zero, and makes each pass in the simplest way, from always returning zero to int.Parse, finding a bug on the way. He runs the tests with NCover, saying coverage means little without test reviews, and sends the audience to do the kata in pairs.

Roy Osherove test-drives a console application that uses the string calculator by calling its Main method in memory from a unit test, after making Program and Main public. He mentions compiler flags and the InternalsVisibleTo attribute for keeping members hidden, then redirects console output with Console.SetOut to a StringWriter over a StringBuilder and checks it with StringAssert. The aim is to connect the string calculator layer to the console layer with a couple of tests, and he moves the console replacement into a helper method.

With a login manager whose save method must also call a logger written by another team, Roy Osherove introduces an ILogger interface so a hand-written fake logger can replace the real one. A fake the test asserts against is a mock object, one it does not assert against is a stub, and the same class can serve as either. He also explains that injecting the fake through a constructor, rather than a property, tells the user of the API the dependency is not optional.

Roy Osherove explains isolation frameworks, which create fakes at runtime, and divides the .NET ones into proxy-based frameworks such as Rhino Mocks, Moq and FakeItEasy and profiler-based ones such as Typemock Isolator, JustMock and Moles. Profiler-based frameworks rewrite the IL at runtime through the CLR profiler API, so they can fake static and private methods; proxy-based ones need interfaces or virtual methods. He compares their APIs on the same logger tests, from string-based NUnit Mocks to Rhino Mocks extension methods, and shows Isolator faking static methods and future instances.

Roy Osherove explains that test reviews spread knowledge and that reviews starting from the tests are shorter because tests show the developer's intent, and names readability, maintainability and trustworthiness as the pillars of good tests. In tests from NerdDinner, ASP.NET MVC and other projects he points out logic, magic numbers, dynamically built expected values and several tests in one method. He also warns against over-specified mocks that should be stubs, allows at most one mock per test, and breaks production code by hand in reviews to see whether a test fails.

Roy Osherove reviews the NerdDinner tests, starting with a single test project that mixes unit and integration tests; he wants them separated into a safe green zone of tests that always pass. A failing HTML rendering test depends on the machine's locale, and he discusses test names, var, magic numbers such as 999, and mock helpers that are really stubs. Different naming conventions show him there was no test review process, and he objects to test dinners created in a hidden helper with a dynamic date.

After the audience reviewed the tests of Microsoft's Unity project, Roy Osherove goes through their findings, including a test with no assert and setup methods that hide the arrange part, which he replaces with factory methods. They discuss bug recreation tests, which belong in a clearly named class, a test that depends on release or debug build flags and is therefore an integration test, and a structure that does not separate unit from integration tests. He ends by writing an Assert.Throws-style helper for MSTest, which lacks one.

Roy Osherove introduces extract and override, from the book Working Effectively with Legacy Code, on a login manager calling a static logger: the call moves into a protected virtual method with as little logic as possible, which a testable subclass overrides. He extends it to simulate a logger exception, check a static web service call and control the machine name rather than build the expected value dynamically. He also uses it to return fake objects, compares it with Moq's protected API, and discusses keeping extracted methods protected or public.

In BlogEngine.NET, downloaded from CodePlex, Roy Osherove looks at the static Send method of a ping manager class, which finds links to other blogs in a new post and sends trackbacks or pingbacks. Since the class is static, extract and override cannot be used, so he creates a static forwarder: the static method calls a non-static copy on a new instance, whose dependencies become virtual methods. He advises having integration tests before such a risky refactoring and sets an exercise: test when trackbacks and pingbacks get sent.

Roy Osherove tests the same blog engine code with Typemock Isolator, explaining why Visual Studio must be restarted for a profiler-based framework and what the Isolated attribute does. He fakes the static methods of the trackback class to verify that Send was called, then follows each failure, which he calls wishful invocation, faking a non-public static method, the blog settings singleton and all instances of a remote file class. The test passes without any debugging, and he asks the audience to get to the same point.

In a talk, Roy Osherove looks at code hosted inside a framework, such as a Silverlight control that cannot be created in a unit test, and at Microsoft's Silverlight test framework, which runs tests in the browser. He compares faking interaction points with an isolation framework, wrapping the system in role-based abstractions, and excavation, where wishful invocations reveal deep dependencies to fake. Using the open-source CThru framework, he disables Silverlight constructors and methods one dependency at a time, which led to SilverUnit, a domain specific test framework running tests in memory.

Roy Osherove explains how to test validation logic that combines many rules, using a password validator, by testing each rule separately from the logic that combines them. He introduces extract and override, also called the test specific subclass pattern, with a testable subclass that overrides the current time so a backup check does not have to wait seven days. He then writes a validator test first, with flags in a testable validator that set what each rule returns, and tests a single rule method directly using the InternalsVisibleTo attribute.

In a 400 level talk, Roy Osherove builds a domain specific isolation framework that stubs out a third-party system by default, using the Typemock Open AOP API, which hooks into the CLR profiler API. For SharePoint he fakes an SPSite title in one test, writes an interceptor that logs every method call, and uses CThru aspects in a custom test attribute to disable the SPSite constructor and skip SP global methods. He shows SilverUnit using the same approach for Silverlight, unlike Microsoft's browser-based test framework, and ends with a song.