This is a two part series. If you haven’t read the first post, I recommend you read it first.
Now that we have a test runner, some helpful attributes, and an assert class, we can get into the guts of TDD: how to actually write code. Remember, TDD is a methodology for writing code that relies on Red-Green-Refactor. We’re going to first write a test that will fail. We write this test because we know what we want our code to do, but we don’t know yet how we’re going to get there. Next, we’ll write the actual code of our application and try to get the test to pass. Lastly, we refactor and clean everything up. After that’s done, we do it all again, until we’ve written our application.
It’s important to have a standard of naming your tests. The number one quality of good code is the ease of future developers to pick it up and keep working on it. If your tests are poorly named, this is going to cause a lot of pain for those future developers. I like to stick to Roy Osherove’s naming standards when writing my tests. You’ll also probably want to check out more of Osherove’s articles and videos (there are some great ones on YouTube) as you continue your dive into testing, he’s a great resource.
I’m sure you’ll read the article I’ve linked later, but just to keep us moving along, here is the standard set by Osherove:
UnitOfWork_StateUnderTest_ExpectedBehavior
As defined in the last post, we’re working on an application that will print out a pyramid of the given height when given an integer that represents the number of stories.
So, let’s start out with the simplest possible use case: a one story pyramid. We want to have some method that when given the integer 1, we output /\\.
How are we going to accomplish this? We know we’ll have some object that builds the pyramid. You might do it differently, but I’ve decided to have a Pyramid class that exposes a Build method that takes one integer, the number of stories, as a parameter. Now that we know the type of class we want to use and the functionality that we want to expose, but currently do not, we can start writing the test.
public class PyramidTests
{ private Pyramid _Pyramid; public PyramidTests() { _Pyramid = new Pyramid(); } [Test] public void Pyramid_GivenBuildInputOf1_Outputs1StoryPyramid() { var result = _Pyramid.Build(1); Assert.IsEqual(@"/\\", result); }}
A couple of things stand out here. First off, you’ll notice that we’re instantiating our Pyramid class in the constructor of our test class. We could just as easily instantiate this class in each test method, but we don’t want to repeat ourselves. Secondly, you will notice that we’re using out [Test] attribute to let the PyramidTestRunner know that we will want to invoke this method as a test. If we had decorated the method with [Ignore], this particular test would be skipped. Last, we clearly name our test using the standard defined above. It is obvious to the future developer that this is testing the Build functionality in the Pyramid class.
In the actual meat (very expensive meat, that’s why there’s so little) of the test, we call the Build method with the number of stories we want to build and then assert that the method returns a result that is equal to /\\.
In a dynamic language we would now run the test and see that we have not implemented the Pyramid class yet and the test runner would return a valuable stack trace for us. However, since C# is a statically typed language, the compiler will not even build the project until the needed class exists. Let’s add that class now.
public class Pyramid
{ public string Build(int size) { return string.Empty; }}
We’ll that looks pretty empty. Regardless, we’re just trying to get the project to build at this point, which is should.
While working on this I’ve been running without the debugger, just because I feel like I can make progress quicker in this small project. After running the project, you’ll see the following in the console window, followed by a stack trace.
Expected
/\\
Actual
This makes perfect sense. Our Build method returns an empty string, as shown by the “actual” section of our output. This is the Red section of our process. The code builds and runs, but the tests fail. The next step is getting this first test to pass.