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:

[ExpectedException(typeof(ArgumentNullException))]
[TestMethod]
public void CreateWithNullTextWillThrow()
{
    // Fixture setup
    int anonymousNumber = 8;
    string nullText = null;
    // Exercise system
    new Plop(anonymousNumber, nullText);
    // Verify outcome (expected exception)
    // Teardown
}

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:

[TestMethod]
public void CommandQueryWillUpdateNumberProperty()
{
    // Fixture setup
    int expectedNumber = 89;
    int anonymousNumber = 11;
    string anonymousText = "Anonymous text";
    Plop sut = new Plop(anonymousNumber, anonymousText);
    // Exercise system
    sut.CommandQuery(expectedNumber);
    // Verify outcome
    Assert.AreEqual<int>(expectedNumber, sut.Number, "CommandQuery");
    // Teardown
}

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.