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.
In reply to You've gotta have tests! by talexb
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |