Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

autarch (914)

  (email not shown publicly)

Journal of autarch (914)

Thursday October 11, 2007
08:49 PM

Tests? Who needs 'em? Scope creep? Bring it on!

[ #34656 ]

I've been working on a rather huge revision to my VegGuide.Org site for at least a year or so. It started as a rewrite of the UI, but ended up becoming a switch to Catalyst and a UI rewrite and a bunch of new features. Talk about scope creep!

The funny thing about this is that it has defied the common wisdom about projects in a couple ways. First of all, the scope creep isn't really a problem, because I have no deadline. In the end I'll have a better product, it'll just take longer to get there. Ok, that doesn't defy common wisdom, exactly, but it's interesting to me that there are projects where scope creep isn't a killer, and the creep hasn't been demoralizing, since it's almost entirely driven by what I want.

The other funny thing about this project its lack of tests. When I started the move to Catalyst, there were no tests, and I've written a few along the way, but I'm not sure if they even still pass. I admit this somewhat shamefacedly becase I've been a big advocate of testing at my @DAYJOBS.

This is not a tiny project. I have about 16,000 lines of code in modules with almost no docs to speak of (another "mistake"), though that doesn't exclude whitespace. There's also about 6,000 lines of Mason templates.

I've been thinking about this for a while, and I realized that what makes it work is that I have written every single line of code in this project, so it all makes sense to me. I also have a decent memory for code, and I wield a mean grep.

I'm not claiming it's bug-free, but the bug count is surprisingly low given the large amount of code churn. I've never been afraid of refactoring this code base, and this project is basically a 50% rewrite, as I'm rewriting the controller and view layers from scratch. The model has changed, but mostly in an evolutionary way when I add new features or remove dead code. The underlying architecture of the model has remained the same, intentionally, since a 100% rewrite is too overwhelming.

There's no free lunch, however. Without tests, I really can't afford to let another programmer make major changes to the code base. Not only would they be more likely than me to introduce bugs, as the code became less a product of one person, I'd be more likely to introduce bugs.

The common wisdom is right. Tests do prevent bugs, and they're incredibly crucial in multi-person projects, especially when you expect to have turnover in developers, which of course you will on any long-lived project. But it's still funny for me to realize that I've been able to get away without them for so long. I don't know if I'll ever write any serious tests for this code, though maybe that will happen if I decide to make major changes to the model layer.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Has anyone other than you actually tried to use the new system yet?

    I find that when I’m the only one working on some code, my bug count is low even if I don’t write tests, but it’s not as low as I think. The minute someone else starts pounding at the app, all sorts of bizarre niggles crop up that I just never thought to look for.

    Usually they’re all quite easy to fix – but not always.

    But maybe you’re better than me and most others at testing your own UIs. That may we

    • I've had a beta running for week or so and people have been using it. I've gotten some bug reports, but nothing major so far.

      I think part of the reason this may be an exceptional case is that to a large degree I'm rewriting existing functionality with a new UI. I'm not inventing the backend logic and the frontend code at the same time. The backend logic has been around for a few years in the case of most features, and I have a pretty darn good idea of what it should do. The backend code is well tested (from