Unit Testing: "It's a code smell if you're refactoring and there are no collaborators"?

Question

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?

Answer 1

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;
  }

}

Answer 2

Let's say we have a domain class, and this domain class has direct knowledge of the persistence layer using a Repository, which it uses in order to expose an instance-level "Save" method that objects working on the domain class can call to persist changes made without needing knowledge of the mechanism (whether this is "good" design is a discussion for another day). Refactoring the class to expose this Repository as a property and/or constructor argument, thus allowing a mocked Repository to be passed that can ensure the proper call is made, is typically a good thing not only for testing but general maintainability.

Now, this being a domain class, it has state data. Let's assume for a moment that one of the stateful properties has a backing field, and the property accessors test that a new input is valid based on the current one (maybe the new value can never be less than the old one). You need to test this validation, but you find that doing so requires access to the backing field to set an initial value that you'll then try to overwrite. This should be a red flag; if the test needs access to the backing field (which is an implementation detail; no consumer should ever have to know it's there) in order to get the object into a consistent state for a test, then how would production code get a consistent object? If there is a method for production code to do the same thing your test does, then the test should probably mimic that way. If there isn't a valid way for production code to get the object into this state, then why are you testing this scenario?