Possible to unit test code that wasn't initially design to be tested, without changing any code?

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.

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.

Code can be written from the start to be testable. If it is not written from the start with testability in mind, you can still test it, you may just run into some difficulties.

In your hypothetical code, you could test the original code by creating a SalesOrder with a date far in the past, or you could mock out DateTime.Now. Having the code refactored as you showed is nicer for testing, but it isn't absolutely necessary.

If your code is not designed to be tested then it is more difficult to test it. In your example you would have to override the DateTime.Now Method which is propably no easy task.

I you think it adds little value to add tests to your code or the changing of existing code is not allowed then you should not do it.

However if you belief in TDD then you should write new code with tests.

You can unit test your original example using a Mock object framework. In this case I would mock the SalesOrder object several times, configuring a different Date value each time, and test. This avoids changing any code that ships and allows you to validate the algorithm in question that the order date is not too far in the past.

For a better overall view of what's possible given the dependencies you're dealing with, and the language features you have at your disposal, I recommend Working Effective with Legacy Code.

This is easy to accomplish in some dynamic languages. For example I can hook inside the import/using statements and replace an actual dependency with a stub one, even if the SUT (System Under Test) uses it as an implicit dependency. Or I can redefine those symbols (classes, methods, functions, etc.). I'm not saying this is the way to go. Things should be refactored, but it is easier to write some characterization tests.

The problem with this sort of code is always, that it's creating and depending on a lot of static classes, framework types, etc. etc. ...

A very good solution to 'inject' fakes for all these objects is Typemock Isolator (which is commercial, but worth every penny). So yes, you certainly can test legacy code, which was written without testability in mind. I've done it on a big project with Typemock and had very good results.

Alternatively to Typemock, you may use the free MS Moles framework, which does basically the same. It's only that it has a quite unintuitive API and is much harder to learn and use.

HTH.
Thomas

Mockito + PowerMock for Mockito.

You'll be able to test almost everything without dramatically changing your code. But some setters will be needed to inject the mocks.