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 withinGetOutput
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 whatGetOutput
was doing. This would be the code smell he's referring to.