Re: starting to write automated tests

[jplindstrom]

We're just beginning to add tests to a large code base (C++) at work, so I've gone through a little of what you face. A couple of thoughts...

The Perl Medic book is good in general, and also specifically about your situation.

If you have code without tests, it's probably not easy to start writing tests; the classes aren't decoupled enough and there are lots of dependencies all over the place. That's my experience anyway, you may be more lucky.

But you have to start somewhere. You can probably nail down the system-as-a-whole using e.g. WWW::Mechanize, just by looking at the system from a user perspective. Start there, that's the most important thing to a) not break, and b) understand/define. Looking at the entire system has the advantage that it doesn't have any dependencies (since it's, uh... the entire system), but the disadvantage that you don't have a stable state wrt data.

When you have the outside view defined and tested, start at the bottom and try to break out classes and functions to test. Start with very, very simple tests, often it's a lot of work just to instantiate an object without all the other objects it depends on. Test::MockObject may help you there.

Test as far as you can, then refactor to make it possible to test further. You'll probably come across methods that are too long or too "fuzzy" to test. Those are good candidates to both document and break up into smaller well-defined parts.

Try not to fix bugs at the same time as you refactor, tings will easily get mixed up.

At times you may need to refactor without having the safety net of tests, but sometimes life just sucks, eh? :)

Well, that's all I could think of just now.

Good luck!

/J

[geektron]

If you have code without tests, it's probably not easy to start writing tests; the classes aren't decoupled enough and there are lots of dependencies all over the place. That's my experience anyway, you may be more lucky.

oh, i won't be as lucky. i started documenting the whole ordering process yesterday, and it's the usual mess. in an attempt to decouple some functionality, modules are sliced too thinly. in other cases, too much goes on in a module that really isn't related.

Try not to fix bugs at the same time as you refactor, tings will easily get mixed up.

i've already learned *that* one the hard way. never again.