I have a bit of a challenge and I am not sure how to approach this. We have a very very large project (that is about 5 years old). The code base is HUGE so a full refactor is out of the question.

What we will be doing is refactoring bits of code as we use those parts (this is backend code, which we will be using on a frontend system)

The existing code has got zero abstraction, and we want to build unit tests for it. We use the RhinoMock framework and the call from my superiors are that we need to add explicit interfaces to the code, thereby abstracting it so that we can mock the objects in RhinoMock.

I have one broader and one narrower question: 1) Is an explicit interface the best option? Or should I suggest some other technique...

2) Can anyone suggest a high-level approach to this type of code refactoring? I've never been in a position where I have had to add explicit interfaces to existing code. (The legacy code is Managed C++ by the way)

Thanks in advance for your answers. Also, if this question is in the wrong place or too broad, I do apologize.

  • 1
    I have ordered the Working Effectively with Legacy Code book as well, just waiting for delivery. Jun 11, 2013 at 6:31
  • 1
    Picking up that book was going to be my suggestion. Glad you are pointed in the right direction. It's packed full of techniques for this sort of problem. The paper's a good read while you're waiting on the book. objectmentor.com/resources/articles/… Jun 15, 2013 at 23:08
  • Thank you so much! Going to start reading the paper tomorrow morning. I really appreciate it. Jun 16, 2013 at 19:11

1 Answer 1


This is one thing that annoys me about unit test frameworks - you have to change the way you code, just so you can use the unit test framework.

There are others - cppunit for example does not require interfaces inserted everywhere which, for a legacy codebase in C++, might be a better solution.

The other alternative is to split chunks of code away from the massive codebase and reimplement them as separate projects, then refactor those in isolation.

Of course, you could just say unit testing a legacy codebase is too hard,and you should spend your efforts on automated integration testing instead. That's the way testing used to be done, and still should be used heavily even with unit-test-enabled codebases.

  • Thanks for the reply. I do agree with your point on the annoyance of changing the code just so the framework functions. Does cppunit allow mocking? The big thing is that adding explicit interfaces are a requirement. I was hoping for a 'best practices' type of approach to doing so. This is unfortunately unavoidable. As far as the integration testing goes, this will happen (and does happen, if I'm not mistaken) but is not sufficient for our purposes. (We're trying to enforce a new way of doing things.) Thanks for the answer! Jun 11, 2013 at 10:13
  • I'm not sure of cppunit, I only used it without needing to mock; but GoogleTest and GoogleMock do (obviously!). Maybe try creating a unit test project that includes those source files from the original project that can be easily tested, and hit the others with automated integration testing instead - testing them is what really matters, not the mechanism used to do the testing.
    – gbjbaanb
    Aug 10, 2013 at 23:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.