If your code has been "running without a hitch" and "an old project" (which I assume means you are no longer actively updating it) why are you adding tests?
Out of curiosity, what's the ROI that you see in adding tests to that project?
For some reason clients tend to get upset when things that were working suddenly break (they don't even care if it as legacy code base!).
Joking aside, in order to effectively prevent that, a test suite must be in place to prevent regressions when you change/add code. If there isn't one, you need to decide between cranky clients or the nastyness of adding test to legacy code.
> For some reason clients tend to get upset when things that were working suddenly break (they don't even care if it as legacy code base!).
Another sad truth to consider is that just the process of refactoring your code to add tests can just as easily break functionality. I've learned this the hard way.
> (which I assume means you are no longer actively updating it)
I believe __abc was basing his comment off the assumption that the code wasn't being actively developed, which significantly reduces the ROI of adding tests to an existing project.
Sounds like it's more back to the OP's response below, that it's an exercise in learning.
I think the author is looking at it as more of an experiment than a valuable project with a positive ROI. As jader201 said he will probably discover that it's a pretty tough thing to do when the code wasn't written with testing in mind. I also believe he will find issues exposing parts of his code to be tested.
Out of curiosity, what's the ROI that you see in adding tests to that project?