Partager via


Ignore Irrelevant Return Values

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.

Comments