Test-Driven Development
Although I was already familiar to the Test-Driven Development (TDD from now on)paradigm, today I finished reading Kent Beck’s Test-Driven Development: By Example and found some useful tips and ideas I would like to point out.
Before starting there’s an advise I would like to give, and is what I always try to remember when writing a test or even code. This is that tests are part of the Code Documentation. It is very important to have this into account when coding and testing, for it is important that others can understand what are you testing, what should they expect as the result, and how you’re testing it.
Simple step-by-step Sum-Up
Taking Kent’s rules and set of steps, and by adding some of my own, I created this diagram. I find very useful when it comes to remembering TDD’s basic ideas.
The To-Do List
It’s very important the use of a To-Do list, in which we should add all the things that we realize must be done in other to completely test/implement all what needs to be done.
For example, imagine we are writing an Equals test for a recipe.
[TestMethod]
public void TestEquals()
{
Assert.AreEqual(new Recipe(1), new Recipe(1));
Assert.AreNotEqual(new Recipe(2), new Recipe(1));
}
Recipe’s constructor receives the ID and two recipes are the same if their ID is the same.
Now we implement the Equals method. In order not to extend myself too much, I will cut some step off of TDD.
public override bool Equals(object obj)
{
return this.Id == ((Recipe)obj).Id;
}
As you can see, I’m not checking if the object is null, neither if it is actually a Recipe I’m comparing “myself” to. This doesn’t matter right now, but as I realize what I’m missing, I should add it to my To-Do List, and come back to it later. Remember this is just an example, I’m not sure I’ll do this in separate steps to be honest.
Isolation
It’s desired that every test is absolutely isolated from the rest, this is, the failure or success of a test shouldn’t affect in any way the following tests result. In order to do this, some good tips are:
-
Separate tests in classes. It’s not necessary to have one test class for each real class, but yes to have well organized set of tests so that everyone who reads it understand (as I stated before) what you’re testing, and what should they expect as a result.
-
Separate tests in methods. It is very important that tests keep small and simple. To achieve this is a good practice to separate the different tests in different methods. It’s also useful using clear test methods names.
-
Not caring that much of Performance. This is a personal tip, and goes against my “programming philosophy”. Sometimes is better to have duplication when creating tests, in order to assure the isolation, than having a very efficient code without any duplication, taking the risk of breaking the isolation.
Test Sections.
I was going to state this as good practices, but giving it a second though I realized its a bit more than a “good practice”.
Even inside a test method, I like to order the code pieces into three different states:
-
Declaration and instantiation: We declare and instantiate all the object that are to be used for testing.
-
Work: We work with the objects. I couldn’t find a better way to explain this, in other words, what we do is what the test is supposed to be testing.
-
Assert: We assert the actual data against the expected one in order to determine if the test succeeded or failed.
Good practices
This are some good practices I could retrieve from the book and from my personal experience. I believe in constant learning, so I won’t call this practices “Final”, but I think they’re a good starting point.
-
Try to start writing the Asserts First. By doing this you’ll have a clear view of which the result should be.
-
Make the Actual and Expected Data evident for any outsider that is reading the tests.
-
When working alone, leave the last test broken. By doing this, when you go back to work the next day, you have a starting point.
There’s much more to be said about TDD, but I wanted to give a quick-pick of the paradigm, I’ll go deeper into it in further posts.