You've gotta have tests!

[talexb]

I've been building an ecosystem of scripts for a client over the last few months, and recently I needed to make use of some functionality I'd left in place in one of my modules. Before starting development, I checked to see how the module tests were laid out, in order to give me more insight into how the module works, since I wrote it a few months ago.

Then I discovered there were no tests.

Narrator: A vague sense of unease flitted through the developer's mind, but he resolutely shrugged it off.

OK, no problem -- I'd just write the tests, as it was a fairly simple module.

Narrator: But it wasn't as simple as he imagined it to be.

After writing the tests, I came to the realization that the way I'd written the module meant it wasn't as extensible as I originally thought. And tests might have revealed that shortcoming.

So I spent some development time more clearly defining what I wanted to module to do, how it should be called, and made changes in one of the scripts that use the module. And found some more issues.

Narrator: Several cups of coffee later ..

The good news is that I now have a module that works the way I need it to, complete with tests that show that it works correctly. All of the scripts that use this module have been updated. And tomorrow I can start work on the feature that uses this improvement.

But the moral of the story remains: It doesn't matter how simple a module is. As soon as you decided you'd put some logic into a module -- that's the point that you should have also written the tests that prove that the module's logic is correct. There's not no excuse for skipping that part.

You've gotta have tests!

Update: Minor edit: not -> no in second to last paragraph.

[Your Mother]

++. The thing about tests is they feel foreign at first and like a huge hit. I think it’s probably three times harder to write the tests than the code; ballpark, back of the napkin. So a one month project might be a four month project if all testing, fixtures, mocking, and build niceties are met. The thing about that is that it cuts debug and future related development and refactoring and customer upset time—and maybe training time since reading tests is a perfect way to learn a code base—down geometrically. So a two day bug is a two hour bug. It won’t make those three months up immediately but after a year… it’s probably paying interest and dividends.

And tests eventually become fun to write. At this point, I enjoy writing tests almost as much as greenfield code and much more than dealing with legacy code.

[talexb]

At this point, I enjoy writing tests almost as much as greenfield code and much more than dealing with legacy code.

Right .. and I find tests give you a much more nuanced understanding of what the module does, and really clarifies your thinking. I believe legacy code with tests would be a lot less scary than what you usually see, code without tests.

[toolic]

... and run coverage (Devel::Cover) to prove the tests hit what you expect them to hit.

[eyepopslikeamosquito]

Thanks for describing your specific real-world experience - which adds support to the many theoretical points I made in Re: Winning people over to better development practises (TDD).

[TheloniusMonk]

Narrator: This has nothing to do with Gollum.
Yes it does!
Who said that?
Wasn't me!