Unit Testing: Naming Conventions

One of the most important aspects of Unit Testing is readability. If your tests are properly named, as well as your variables, it leads to self-documenting code that is easy to follow. It is common practice in TDD for the progammer to write their own tests. In the companies that I have worked for, it is common for many developers to work on the same code base. If there is no standard or guideline for naming conventions, trying to decipher the code can be a headache.

Naming Conventions
I will always stress the importance of testing the behaviour of the code rather than the implementation. This starts with naming your test cases appropriately. Take the following code as an example:

public Connection getConnection(String connectionName)()
{
    Connection connection;

    switch(connectionName)
    {
        case "PrimaryDb":
            connection = ConnectionType.ONE;
        case "SecondaryDb":
            connection = ConnectionType.TWO;
        default:
            connection = null;
    }

    return connection;
}

Now let's analyse the following test case names:

• getConnection_Can_Get_A_Database_Connection
• getConnection_canGetTheConnectionForDatabase1
• canGetTheConnectionForThePrimaryDatabase

From my perspective, the last option is the best one. The first option says nothing about the database we are trying to get a connection for. I also prefer not to over use underscores when separating words. Names become too lengthy. The second option reads nicer than option 1, but the method being tested is indicated. For maintaining code, this can be overkill. If you're writing your tests while you're coding you know how often refactoring occurs. It is a pain to have to manually change the name of each of your tests when changing the name of a method. Most IDE's have a refactoring option which automatically rename all references. The third option specifies the behaviour we are testing and uses camel case so that it is easy to read without being too lengthy. You may need to start each test case with "test" depending on the framework you're using. Most xUnit frameworks allow an "@Test" annotation.

Naming Variables
Current IDE's will most likely be equipped with auto-complete features. They can save a huge amount of keystrokes and if you are writing in a losely typed language like PHP, can help ensure you are not accidentally creating new variables. As I mentioned previously, self documenting code is an extremely important aspect of Unit Testing and variable names are part of that. Take the following example of a test case:

@Test
public void canReduceTheAmountOfFundsInASavingsAccount()
{
    account = new Account(AccountType.SAVINGS);
    account.setFunds(50);
    account.subtractFunds(35);
    assertEquals(15, account.getFunds());
}

The test is very easy to follow because the tester used descriptive variables and an Enum to specify the type of account. I have seen people take shortcuts and may name their variables "a" or "act". That may save a couple keystrokes, but it is much harder to follow when revisiting failed test cases.