Unit Testing – Is It a Code Smell if Refactoring Has No Collaborators?

code smellcode-qualityunit testing

I'm reading The Art of Unit Testing by Roy Osherove. I'm at section 7.2 Writing maintainable tests where the author has this note about code smell:

NOTE: When you refactor internal state to be visible to an outside
test, could it be considered a code smell (a sign that something might
be wrong in the code's design or logic)? It's not a code smell when
you're refactoring to expose collaborators. It's a code smell if
you're refactoring and there are no collaborators (so you don't need
to stub or mock anything).

EDIT: What the author means by "collaborators" is dependencies. Some of his examples for dependencies are classes that access a database or that access the OS's file system. Here is where he defines stub and begins to use the word collaborator:

A stub is a controllable replacement for an existing dependency (or
collaborator) in the system.

The author doesn't have an example of this code smell and I'm having trouble understanding/picturing what this would look like. Can someone explain this a little more and perhaps provide a concrete example?

Best Answer

I think this is what the author is getting at.

In my code sample, I have a timing window that takes an output quantity plus a start and stop time. The intent is to draw an output window over a 24 hour timespan. A wrinkle is added when start time is greater than stop time because that's a timing window that spans midnight.

You can write unit tests that fully exercise the object without exposing the private variables. Those private bools and timespans are the collaborators he's referring to when exposing the internals for unit testing. According to the book, exposing those internals would NOT be a code smell since they are collaborators.

Exposing the double output would be a code smell since it's not a collaborator - it's an element explicitly hidden by the class itself that has conditional logic within GetOutput to determine what should be returned.

Digging into the bools / timespans would make the unit tests more comprehensive. He says this is good.
Digging into the double output would require additional logic in your unit test that mirrored what GetOutput was doing. This would be the code smell he's referring to.

public class TimeWindow
{
  private bool isConst;
  private bool spansMidnight;
  private TimeSpan start1;
  private TimeSpan stop1;
  private TimeSpan start2;
  private TimeSpan stop2;
  private double output;

  public TimeWindow( double out, TimeSpan start, TimeSpan stop)
  {
    output = out;

    if( start == stop )
      isConst = true;
    else if( start > stop )
    {
      spansMidnight = true;
      start1 = midnight;
      stop1 = stop;
      start2 = start;
      stop2 = midnight;
    }
    else 
    {
      start1 = start;
      stop1 = stop;
    }
  }

  public double GetOutput( TimeSpan time )
  {
    // some logic here on what / how to return
    ...
    return output;
  }

}
Related Topic