I have been doing a fair amount of TDD training recently. The developers attending the courses are generally fairly experienced developers, but tend to have little or no experience of TDD.
A challenge with training is that you are forced to think about ideas and concepts on a whole new level as you have to relay this to your audience in a way in which they can understand.
If you are new to TDD and it seems like a pretty complicated strange world, be aware TDD does come with a fairly steep learning curve. Writing a test method with an assert is relatively straight forward. Writing a full test suit that contains a set of fast, reliable, clean, loosely coupled and readable tests is a whole lot harder. TDD is a pretty in depth subject and learning how to do it right takes a fair amount of time and practice.
One very important aspect of writing tests is test naming. Tests tend to live for the lifetime of the application and are a form of living documentation. As developers spend a far larger portion of their time reading code than actually writing code it's important that what they are reading makes sense. Tests with names that do not make sense can make a developers job a whole lot harder when they have to work with these tests later.
In this blog post I want to share my thoughts on what a good test name is and how to find these good test names. Here is a statement that summarizes my current thinking on test naming:
"A test name should show your intent, the test body should be a clear example of this intent."
One thing to note, although it's not the aim of this blog post, when naming your tests you want to find a test naming convention that you are happy with and stick with it.
I tend to use the following convention.
<SUT>_Given<Context/Scenario>_Should<Expected Outcome>
Where:
SUT - is the system under test. This is generally any public method or property on a class that contains logic.
Context/Scenario - describes what you are trying to achieve with this test.
Expected Outcome - did you achieve the result you expected once the SUT has run.
Now that we got that out the way back to test naming. I like find to get the best names for your tests you really need to think of the names in terms of the domain that you are dealing with. The best names may not come to mind initially, but as you get to know your domain better it, will become easier to find the names. If your name isn't perfect when you initially write the test that's fine. Remember you should always be thinking about refactoring your code and this applies as much to your tests and test names at to the actual production code you are writing.
What I find tends to happen when you try to name a test around a concept you are unfamiliar with, your names tend to be very specific.
I'll demonstrate this with an example:
Let's say you are writing a method to calculate a person's age. You may start with a method like this
[Test]
public void CalculateAge_Given_DateOfBirth_20Jan2014_And_CurrentDate_20Jan2014_ShouldReturn_0()
{
-- Arrange
var expectedAge = 0;
var dob = "2014-01-20";
var currentDate = "2014-01-20";
-- Act
var age = CalculateAge(currentDate, dob);
-- Assert
Assert.AreEqual(expectedAge, age);
}
The test above isn't a bad starting test. I am testing on an interesting boundary and the code shows a good example of what I am trying to do. The test name however, describes my example as opposed to describing my intent. So what is it that I am actually trying to test here. If I consider the domain can I rename this test to more accurately describe my intent?
How about this:
[Test]
public void CalculateAge_GivenItsTheDayThePersonIsBorn_ShouldReturn_0()
{
-- Arrange
var expectedAge = 0;
var dob = "2014-01-20";
var currentDate = "2014-01-20";
-- Act
var age = CalculateAge(currentDate, dob);
-- Assert
Assert.AreEqual(expectedAge, age);
}
I think you will agree with me that the second test name makes a whole lot more sense. The first test name is very specific to the problem, but with the second test name I have generalized just a bit. It's had a huge impact on the readability of the test and now clearly shows my intent. You could of course generalize further :
[TestCase("2014-01-20", "2014-01-20", 0)]
[TestCase("2014-01-20", "2015-01-20", 1)]
[TestCase("2014-01-20", "2015-01-19", 0)]
public void CalculateAge_Given_DateOfBirth_And_CurrentDate_ShouldReturn_Age(datetime dob, datetime currentDate, int expectedAge)
{
-- Arrange
-- Act
var age = CalculateAge(currentDate, dob);
-- Assert
Assert.AreEqual(expectedAge, age);
}
At this point we have a general purpose test that has test cases (examples) of what we are testing. Once again this test is not clearly showing your intent. You are forced to look at the examples to try to work out the intent. If you considered tests names on a continuum from very specific to very general, you want to try to find a name that hits the sweet spot. It's not so specific that you need to look at the code to work the intent and it's not so general that you are looking at the test cases to work out the intent.
