Some Actual Real Tests!
For these examples I will be using the Calculator Kata designed by Roy Osherove, starting with a solution containing two empty projects, the production project “CalculatorDomain” and the test project “CalculatorDomain.Tests”.
The first test
The calculator add method should take an empty string and return zero.
First off create the calculator test class and add the test code until the solution won’t compile
At this point its time to write production code, and creating the calculator class is enough to make the tests compile, so its back to the test code to continue writing the test
and now we require an add method in the calculator class, creating a stub of this method is enough to make the solution compile.
so back to the test code and finally adding the assert clause allows us to run the test, and get our first fail.
One of the tenants of TDD is that the code written to make a test pass should be the simplest possible, in this case we simply have to return 0! Which makes the test pass.
As this small demonstration shows calling this development technique “Test First Development”, is not strictly accurate, as the test and production code is actually written concurrently, which makes the idea of writing the tests a lot easier, because the test is written in concert with the production code, the result is all the code written, is by definition testable, which as many can testify cannot be said of code which is written before tests.
Once a test is passing, the next stage of the development process is refactoring, which is where duplication in the code is removed and the structure of the class is created, methods are simplified, and the code is structured to follow the “SOLID” principles of good code design. The tests are then rerun to ensure that the code still behaves as expected.
In this case we only currently have one test so there is no refactoring to do yet, and the production code is as simple as it can be so again no refactoring.
Next time test two!