Question

Is it generally accepted that you cannot test code unless the code is setup to be tested?

A hypothetical bit of code:

public void QueueOrder(SalesOrder order)
{
   if (order.Date < DateTime.Now-20)
      throw new Exception("Order is too old to be processed");
   ...  
}

Some would consider refactoring it into:

protected DateTime MinOrderAge;
{
   return DateTime.Now-20;
}

public void QueueOrder(SalesOrder order)
{
   if (order.Date < MinOrderAge)
      throw new Exception("Order is too old to be processed");
   ...
}

Note: You can come up with even more complicated solutions; involving an IClock interface and factory. It doesn’t affect my question.

The issue with changing the above code is that the code has changed. The code has changed without the customer asking for it to be changed. And any change requires meetings and conference calls. And so i’m at the point where it’s easier not to test anything.

If i’m not willing/able to make changes: does it make me not able to perform testing?

Note: The above pseudo-code might look like C#, but that’s only so it’s readable. The question is language agnostic.

Note: The hypothetical code snippet, problem, need for refactoring, and refactoring are hypothetical. You can insert your own hypothetical code sample if you take umbrage with mine.

Note: The above hypothetical code is hypothetical. Any relation to any code, either living or dead, is purely coincidental.

Note: The code is hypothetical, but any answers are not. The question is not subjective: as i believe there is an answer.

---

Update: The problem here, of course, is that i cannot guarantee that change in the above example didn’t break anything. Sure i refactored one piece of code out to a separate method, and the code is logically identical.

But i cannot guarantee that adding a new protected method didn’t offset the Virtual Method Table of the object, and if this class is in a DLL then i’ve just introduced an access violation.

Answer 1

The answer is yes, some code will need to change to make it testable.

But there is likely lots of code that can be tested without having to change it. I would focus on writing tests for that stuff first, then writing tests for the rest when other customer requirements give you the opportunity to refactor it in a testable way.