You have just been handed an application that was developed by others no longer with your company. Been there before? We all have. Probably on several occasions. Can we predict some of the common symptoms?

And here is the fun part: we don't know all of these issues up front. We are basically told where to check out the source tree, and to get cracking. For example, it's only when we run into an issue and seek out documentation that we discover what does (or does not) exist.

Maybe I didn't catch everything you have encountered in that list, but I bet I hit a fair number. I don't want to sound like an embittered software developer, because I'm not. Not every project is like this. But I'm sure we have all had to deal with this at one time or another. So what do we do? We start testing.

But the devil is in the details. Do we write a unit test? What about a thread test or an integration test? You know what? It doesn't matter what type of test we write. In fact, it doesn't matter if we use the right name.

When it's just you and the code sitting in a cubicle, terminology doesn't matter. Writing a test is what matters. If you can pick out one small unit of code and write a test, then go for it! But what if you picked up a jumbled piece of spaghetti code that doesn't come with nicely isolated units?

Consider a system where the smallest unit you can get hold of is a module that parses an electronic file and then stores the parsed results in a database. The parsed results aren't handed back through the API. They just silently, mysteriously end up in the database. How do we automate that?

Congratulations, you just wrote an automated test! It probably didn't qualify as a unit test. In fact, it may look kind of ugly to you. But so what? Maybe it took five minutes to run, but isn't that better than no test at all?

Since the database is the place where we can assert results, we need to have a cleaned out version before every run of our test. This is definitely going to require coordination if other developers are using some of the same tables. We may need our own schema allocated to us, so that we can empty tables at will.

The modules probably suffer from a lack of cohesion and too much tight coupling. While we can try to identify why the code is bad, it doesn't advance our cause of building automated tests.

Instead, we must recognize that if we try to jump immediately into unit level testing, we would have to refactor the modules to support us. With little or no safety net, the risk is incredibly high, and we can feel it! If we try to stick to textbook unit testing, then we will probably give up and deem automated testing as an impossibility.

So we have to take the first step and write the expensive, end-to-end automated test to build the first link in a chain. That test may take a long time to run and not be very comprehensive in what we can assert. But it's a start. And that is what's important. Hopefully, after steady progress in writing more tests like this, we will build up enough of a safety net to go back and refactor this code.