In previous Zero-Friction TDD posts, I've discussed naming SUT and Direct Output variables, as well as the importance of explicitly describing the relationship between input and expected results.

Everything you can do to help the Test Reader understand what's going on increases the quality of the test. Having a naming convention for expectations help in that regard, and it also helps coming up with variable names, thus saving yourself a bit of mental context switching.

My naming convention is to always prefix my expectation variables with the term expected.

[TestMethod]

public void DoStuffWillReturnMessage()

{

    // Fixture setup

    string expectedResult = "ploeh";

    MyClass sut = new MyClass();

    // Exercise system

    string result = sut.DoStuff(expectedResult);

    // Verify outcome

    Assert.AreEqual<string>(expectedResult, result,

        "DoStuff");

    // Teardown

}

In a test like this, the relationship between the input and output is straightforward, but in other cases it may be more complicated. Since tests should explicitly state the relationship between input and output, it may sometimes be necessary to reproduce parts of the SUT's behavior in the test to specify this association.

Do I really recommend duplicating the SUT's code in the test? Isn't this a violation of the DRY principle? And do I really think that embedding complex code in a test is a good idea?

No, no, and no.

What I really mean is best illustrated with an example. Imagine that you want to write an extension method that converts a string to PascalCase. There are several different rules that must be applied to such an algorithm, such as

• Convert the first letter in a word to upper case
• Convert the remaining letters in the word to lower case
• Remove white space

The real algorithm would need to split the string into words along white space boundaries, then loop through this list and perform the conversion for each word, and finally concatenate all the words. However, I don't think you should reproduce this algorithm in any single test.

What you can do instead is to split this behavior into several tests that each test a small part of this specification, carefully avoiding any control flow language features (such as if, switch, for, etc.).

One such test might look like this:

[TestMethod]

public void ToPascalCaseWillConvertFirstLetterToUpper()

{

    // Fixture setup

    string anonymousText = "pLOeh";

    string expectedLetter =

        anonymousText.First().ToString().ToUpper();

    // Exercise system

    string result =

        anonymousText.ToPascalCase();

    // Verify outcome

    Assert.AreEqual<string>(expectedLetter,

        result.First().ToString(), "ToPascalCase");

    // Teardown

}

While the complete implementation of ToPascalCase is more complex, I've extracted a tiny bit of the specification and simulated just that for the special case where there's only one word. Granted, there's a lot of method calls, but I expect that these have already been thoroughly tested, so I use them with confidence. The cyclomatic complexity of the test is minimal.

As an aside, note that I'm using LINQ queries to get the first letter of the string, instead of Substring(0, 1), since I find that the LINQ methods much better communicate intent.

I use a similar naming convention for unexpected values, imaginatively prefixing my variables with the term unexpected.

[TestMethod]

public void CreateThingWillCreateThingWithCorrectGuid()

{

    // Fixture setup

    Guid unexpectedId = Guid.Empty;

    MyClass sut = new MyClass();

    // Exercise system

    Thing result = sut.CreateThing();

    // Verify outcome

    Assert.AreNotEqual<Guid>(unexpectedId, result.Id,

        "CreateThing");

    // Teardown

}

Having a naming convention for expected values not only increases your productivity when writing tests, but also increases test maintainability.