This post is an installment in my series on Zero-Friction TDD.
Often when writing a unit test, the SUT's API will force you to create objects that you really don't care about. As an example, take a look at the signature of this constructor:
public Plop(int number, string text)
To create an instance of the Plop class, you must supply both parameters, but you may not care about their values. You can't just pass in null as the text parameter, because the constructor checks for this and throws an ArgumentNullException if you do. In other words, you are forced to create some non-null text to pass to the constructor, even if its specific value is totally irrelevant to the test at hand.
That sounds a lot like the description of a Dummy, except that such variables are taxonomically different because they aren't Test Doubles. In xUnit Test Patterns, Gerard Meszaros also discusses Anonymous Creation Methods as one way of creating variables like these, so I've lifted this terminology to call them Anonymous Variables.
When naming such variables, I prefix the variable name with anonymous to indicate that I don't really care about the value.
public void CreateWillExposeNumberAsProperty()
// Fixture setup
int expectedNumber = 4;
string anonymousText = "Anonymous text";
Plop sut = new Plop(expectedNumber, anonymousText);
// Exercise system
int result = sut.Number;
// Verify outcome
Assert.AreEqual<int>(expectedNumber, result, "Number");
Naming the text variable anonymousText instead of just text or something similar probably doesn't save me much context switching, but it's a good help for the Test Reader because it clearly indicates that we don't really care about this value.
Even though it's redundant, I also type in Anonymous text as the string value, although this could really be anything. However, it saves me the trouble of coming up with something else.
The same pattern can be used if we want to test the text instead of the number
public void CreateWillExposeTextAsProperty()
int anonymousNumber = 3;
string expectedText = "Anonymous text";
Plop sut = new Plop(anonymousNumber, expectedText);
string result = sut.Text;
Assert.AreEqual<string>(expectedText, result, "Text");
With numbers, the value itself can contain no hint of its origin and usage (like a string can by saying I don't matter), so the name anonymousNumber is the only clear indicator of the number's purpose. It also helps clarify what may otherwise look like a magic number: Why is the value 3? The name gives us an indication that it doesn't matter, and it might as well have been some other value. Without that hint, the Test Reader might have to spend more time before determining whether or not the number 3 carries any particular connotation in this context.
Notice that even though the text variable isn't an Anonymous Variable any more, I've kept the text Anonymous text as the string value, since I don't really care about the explicit value, but only about the relationship between input and output. Again, this is a help for the Test Reader - and remember: That may very well be you six months into the future.
In terms of avoiding context switching when writing tests, this tip falls into the Almost-Not-Worth-It category, but if you combine it with the assistance it provides the Test Reader, it is certainly a valuable habit to pick up.