(results of a discussion in an XP user groupmeeting)
The problem: There is a Huge legacy framework/library that forms the basis of most software developed in a company. But it is almost impossible to test, as user interface code just pokes into the database at will or does whatever other nasty stuff. If you have ever worked in a website building company, you know what I mean. So we want a situation that allows us to use both the framework and unit tests and we also would like to be less rigid coupled to it.
Client code: Abstraction
Maybe the title should read "How to Hide a Dinosaur", as a first approach would be to define some wrappers to abstract things like the database (one of the worst problems). If you can find any traces of abstraction made by others, that could be even a better starting point. I can not fully explain why, but I also thought (and I was not alone in this) that dependency inversion would be of great help too here (let the database talk to you instead of interrogating it). It is just a gut feeling, but it is one I trust. As a nice side-effect, it would almost automatically lay the foundation of a new, by far better designed and testable interface to the library.
How to Hide a Dinosaur
So how do you hide a dinosaur? Well, in pieces. If you are abstracting a specific task, it usually takes not that many classes to do so. The new wrappers are "injection points" where you can inject your test data into the code. Once we can abstract (for example) a data connection, we can define unit tests effectively (Duplicating a significant part of the database is not very efficient).
The Library
As company libraries are usually "guarded" property, it will surely pay off to know who you have to convince to be allowed to make the system testable. "Dinosaurs" are not a disaster that suddenly happen, they are a combined technical and organizational problem. Building a new Dinosaur may look like the solution in a technical sense (it will to some staff), but the new Dinosaur has the same choice as its predecessor: die out or evolve. So if your company decides to build a new Dinosaur, try to make it ready for some evolution.This is also the time to use your source code control system. If it can tell which code is used in which projects, it can help you give an impact analysis of some changes. Or the necessity for them. The ability to link sources across projects also seems vital, to help the new system evolve. If code cannot be reused among projects, it will only grow apart.
