Matt recently made some changes to a “legacy” application. Unlike most legacy applications, this one was well instrumented with unit tests. Matt’s changes failed some of those unit tests, so he went to look and see what he needed to change to update the tests.

With those extremely helpful naming conventions , and a complete and utter lack of comments, Matt was left reading the source code of the tests, in an attempt to understand what they were actually testing for. 

/// <summary>
///
/// </summary>
public void TC33()
{
   Start(_uri1, _u1, _ag1, null);

   _ag1.Answer();
   _ag1.PublishState(UserState.Busy);

   _ag1.Hold();
   // Somehow detect that hold fails. How? Fix this later.
   Thread.Sleep(500);
   _ag1.Retrieve();
   Thread.Sleep(500);
   Finish(_u1, _ag1, null);
}

The only comments Matt found in any method generally followed that pattern. There were a few “I don’t know what this code does,” and “Do something, somehow, figure it out later.” Many of the tests, like the one above, didn’t actually assert anything.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!