This is an installment in my Zero-Friction TDD series.
Sometimes, you don't care about the return value from a particular operation. The simplest example is if you want to check that creating a new instance of a specific type will throw an exception if supplied with wrong parameter values:
public void CreateWithNullTextWillThrow()
// Fixture setup
int anonymousNumber = 8;
string nullText = null;
// Exercise system
new Plop(anonymousNumber, nullText);
// Verify outcome (expected exception)
In this example, even though the new operation is supposed to return a value, we don't care about it, since we only want to test that the correct exception type is being thrown. To save myself from having to stop and think about a variable name (even though in this case, I'd just have used sut), I prefer to not declare and assign the variable at all.
In general, I believe that APIs should follow the principle of Command-Query Separation, but sometimes it makes sense to break this rule. When you have an operation that both return a value and have side-effects, testing the side-effect via state-based testing doesn't require the return value.
Imaging that you have a method with this signature:
public object CommandQuery(int number)
Testing the side-effect may look like this:
public void CommandQueryWillUpdateNumberProperty()
int expectedNumber = 89;
int anonymousNumber = 11;
string anonymousText = "Anonymous text";
Plop sut = new Plop(anonymousNumber, anonymousText);
// Verify outcome
Assert.AreEqual<int>(expectedNumber, sut.Number, "CommandQuery");
Notice that I've ignored the return value of the CommandQuery method.
Save yourself the time and effort it takes to declare and assign variables if you don't use them anyway.