TDD in .NET in Hebrew

Roy Osherove lays out the three days (unit testing basics, mock objects, legacy code) and separates unit testing, how to write tests, from TDD, when to write them. He asks why teams with many tests still give up on them: tests that check nothing, tests that cost too much to maintain, and unreadable test names. He defines a unit as a unit of work that starts at a public method and ends in a return value or exception, a state change, or a call to a third party such as a logger.

Roy Osherove argues that unit tests and integration tests complement each other, then introduces the xUnit family of frameworks, from SUnit through JUnit to NUnit, which the course uses, and its competitor MSTest. He explains the arrange, act and assert parts of a test, the TestFixture and Test attributes the runner finds through reflection, a three-part test name separated by underscores, putting the expected value before the actual one, and one logical assert per test. He starts a calculator class library in Visual Studio with ReSharper, adds a separate test project and installs NUnit with NuGet.

Roy Osherove shows where NuGet comes from and writes the first calculator test with ReSharper, explaining why he picks plain inputs such as 1 and 2 over numbers like 1337 that make a reader wonder. He prefers the TestDriven.NET runner, maps a keyboard shortcut to rerun the last test action, and runs any method under the debugger without a test. He adds a test for negative numbers, keeps random values and logic out of unit tests, and replaces the SetUp method with a factory method so each test stays readable on its own.

Roy Osherove merges similar tests with NUnit's TestCase attribute and compares ways to test an exception: try/catch with Assert.Fail, the ExpectedException attribute, which can pass when another line throws, and Assert.Throws with a lambda. He treats a TearDown as a sign of an integration test, to be kept in a separate project, and names the continuous test tools AutoTest.NET, NCrunch and Mighty Moose. He then introduces the three TDD steps and starts a calculator memory feature test first.

Roy Osherove builds the calculator's memory feature with TDD: first a failing test, then the simplest code that passes all tests, which he describes as code with as many assumptions as possible, near the top of the function and with few ifs. The group designs the API through the tests, and he writes future tests down as comments so there is one problem to solve at a time. He also answers questions on organizing many tests, given/when/then in behavior driven development, and setup methods.

Roy Osherove notes that by the end of the first day most participants were writing the test first and arguing about implementation, design and readability rather than whether to test at all. He previews the second day: replacing the console earlier was a kind of mock object, the difference between a mock (which the test asserts against, one per test) and a stub (any number per test), and frameworks such as NSubstitute. He asks everyone to redo the string calculator exercise from scratch for ten to fifteen minutes every morning so they do not forget what they learned.

The second day opens with participants' questions. Roy Osherove suggests adding a command-line step that runs the tests in the build and fails it, and on UI testing contrasts recorded WinForms tests with Ruby's Capybara, which can run headless and test JavaScript, while recommending page logic such as validation be extracted into classes that unit tests cover. He keeps DateTime.Now, random numbers and threads out of unit tests, gives three ways to test code that ends in storage or a request (abstraction, a fake, or an integration test), and advises using mock objects as little as possible.

Roy Osherove explains why a test replaces a dependency, using a manager class whose save method calls a logger that may be unfinished, buggy or slow. He adds a logger interface passed through the constructor and a handwritten fake logger in the test file; a fake is a mock when the test asserts on it and a stub otherwise, as in a second test where a stub logger throws and a fake web service is asserted. He advises one mock per test and no logic in fakes or tests, and shows NCrunch running tests in the background.

Roy Osherove explains that isolation frameworks generate fakes in memory that return values, throw exceptions and verify calls, and that any fake is a mock if the test verifies against it and a stub otherwise. He splits .NET frameworks into constrained ones such as Rhino Mocks, Moq, FakeItEasy and NSubstitute, which can only fake virtual or interface methods, and profiler-based ones such as Typemock Isolator, JustMock and Moles, which can also fake static methods. He then rewrites the logger tests with NUnit's basic dynamic mocks, Rhino Mocks and Moq, comparing string method names with lambda expressions, strict and non-strict mocks.

Roy Osherove continues with Moq, showing callbacks, Verifiable and VerifyAll, and overriding protected methods, and warns that verifying many interactions you do not care about is overspecification, explained with a story about sending his son to buy pizza. He then writes the same logger tests with FakeItEasy, whose API starts with A and whose error messages he finds better than Moq's, and with NSubstitute, and recommends starting with one of the newer frameworks. Asked about profiler-based frameworks, he says they run slower but are used to get coverage on legacy code before refactoring.

With NSubstitute, Roy Osherove shows recursive fakes: when a person object is faked, its manager property returns a fake as well, instead of each returned object being set up on its own line. He says Isolator was the first framework to do this and that it makes tests more maintainable, because a new property or method that returns an object is faked by default. He then sends the group back to the exercises, up to the login manager that uses a static method.

Roy Osherove turns to dependencies that cannot be injected through a constructor, such as a call to a static logger, and introduces extract and override from Michael Feathers' book Working Effectively with Legacy Code, which he recommends. He moves the call into a protected virtual method with no logic and has a testable subclass of the login manager override it and save the text in a public field for the test to check, noting that in real legacy code he would first have an integration test in place. To concerns about exposing such methods he answers with internal methods and InternalsVisibleTo.

Roy Osherove applies extract and override to the machine name as well, then explains why it does not suit time, which is used throughout a system. Instead he adds an API to a central system time class so tests can set the current time, and resets it after each test because the change is static and affects other tests. He argues that a static class is not bad design in itself, suggests making the setter internal and visible to the test assembly, and sends the group to implement it in the exercises.

Roy Osherove shows Typemock Isolator, a profiler-based framework for code that cannot be refactored: its API starts with Isolate, it can fake any class, including ones with private constructors, and it verifies calls with any or exact arguments. He explains the Isolated attribute that cleans up static fakes after each test and the profiler environment variables that Visual Studio plugins and command-line runners set, as Moles and JustMock also need. He then fakes static methods, future instances and non-public members without touching production code, mentions SilverUnit and CThru, which he built on Isolator, and asks the group to test the original exercise code this way.

Roy Osherove previews the third day: the group will take an open-source project that has no tests and is mostly static and write tests for it both without and with Isolator, learning another refactoring technique on the way. They will also turn the practices discussed so far into a more formal set of things to look for, review tests from open-source projects, and, if time allows, write tests for the participants' own code.

Roy Osherove groups his rules into tests that are readable, trustworthy and maintainable, and tells how a bug in a test helper cost him and a pairing partner 90 minutes on a Go engine built with TDD. For trust he separates unit tests from integration tests that need configuration, so a failing unit test is never "fine", and recommends code reviews that start from the tests. He argues that code coverage means little without reviews, then reviews a test from Microsoft's Unity source that has no expected behavior in its name, a loop and several asserts, and prefers readability to removing duplication.

Roy Osherove advises against tests that depend on each other's order and against magic numbers such as a 37 in the Unity tests, preferring the simplest value or a named variable. He shows an ASP.NET MVC test helper that builds a fake HTTP context with Moq and is full of ifs, suggests overloads instead, and wants expected values hard-coded rather than computed, so a production bug is not repeated in the test. Reviewing a NerdDinner test named "should be valid when all properties correct", the group debates splitting it into one test per validation rule.

Roy Osherove ties maintainability to a unit of work that runs from a real entry point to an end result, calling checks on how things are done overspecification, and wants isolated tests that can run in any order. He reviews an ASP.NET MVC test that loops over link overloads, which hides which overload failed, and a Moq test with two verifies where the data provider should be a stub. On readability he covers project conventions, a NerdDinner test with an unexplained 6, and a fake membership provider whose secret input protocol belongs in public constants.

Roy Osherove recommends ordering tests so that each one changes only one thing in the inputs compared with the test before it, such as one more character in a string, which makes the pattern readable and shows how the feature was built step by step. He sums up his three pillars, tests that are easy to read, easy to maintain and trustworthy, and calls TDD almost the only way he knows to see tests both fail and pass, though bugs in tests can still mislead.

Roy Osherove introduces the legacy project for the third day, the BlogEngine.NET blog engine, which has no unit tests but has integration and acceptance tests. Some are written with WatiN, which is based on Ruby's Watir and works mainly with Internet Explorer, and others in a framework whose tests are written in Razor pages that run in the browser; of 20 tests, five fail. The exercise is to understand why and make all the tests pass, get to know the code and its dependencies, and try writing a new test before refactoring.

Roy Osherove sets out to test the static Send method of a class named Manager in the ping namespace, which sends a trackback or ping for the links in a post or comment, and suggests finding its dependencies by calling it and seeing where it fails. The calls that send a trackback or ping are the end results, and the tests should prove the loop and each if. Because the class is static, he introduces instance delegator: remove static from the class, move the logic into an instance method that the static method calls on a new manager, then extract and override settings such as the trackback check in a testable subclass.

Roy Osherove explains that a fixture setup runs once before all tests and usually means something slow is initialized, and agrees that the refactorings made the code more testable, not better designed. On whether to fake the method that parses the links out of the content, he prefers to keep as much code in the unit of work as stays fast, in memory and readable, fakes threads, processes and the file system, and calls the choice the art of unit testing; a debate on testing private methods follows. Each pair then writes two or three tests for real production code that go into source control.