I wanted to write to say you’re not refactoring. The term refactoring was created in the context of extreme programming [er, I should have said "popularized"] and it was defined as reworking code that’s under test. Without the tests, you’re just rewriting, working without a net. That’s why your code ends up buggier.

I don’t write to be pedantic. (Well, OK, maybe a little. I am a programmer, after all.) I write because I also used to wonder what all the fuss was about ‘refactoring’ when it really just seemed like a dangerous bunch of nonsense that left my code with new bugs. I didn’t do any automated testing at the time and didn’t realize how valuable it can be.

I still haven’t drunk the XP kool-aid, but having a good test suite means I don’t code in fear that I’ve broken things, or feel awful when a bug slips into production because I didn’t remember to hand-test some weird situation. I’ll even write tests on the personal projects I’m just hacking away privately at — yeah, I probably will just do a little unit testing instead of a really comprehensive, robust system, but even a bit helps.

He responded that a game like Unangband is especially hard to test because it has so many moving parts and much of the gameplay is generated. It does have a very high-level test, an automated player. I wrote back:

I don’t really think anything is too complex for test cases. You have a ‘pick up’ command that, if the player is standing on an object and has inventory space, removes it from the world and puts it in their inventory. There’s a fair amount of data structure you have to mock (which is not the easiest thing in the world in C), but you can know the basic command works even because you test all the really weird corner cases about when the player is polymorphed into a creature without hands or something. I’d bet as simple as the command usually is, you’ve broken ‘pick up’ at least a few times. It’s a safety net you build one strand at a time, like a spider web. You may still be able to fall through (especially at first), but sometimes you’ll catch a strand and be glad you built it for yourself.

The other part of complexity is that thinking about testability changes how you structure your programs. You force yourself to decouple different parts of code because you want to be able to test them in isolation from each other — that this improves your overall design is a nice side-effect. That you can spend less time worrying about or kicking yourself for breaking something ‘so obvious!’ is the real one.

You may enjoy the book Refactoring: Improving the Design of Existing Code, it’s the classic in the space. Though my money’s on the later book Working Effectively with Legacy Code, which is a couple hundred pages on how to go from cursing your predecessors to a reliable codebase. Saved my bacon at a previous job. I know Unangband is your hobby rather than your job, but I suggest them because they’ve helped keep my hobby code more fun than frustrating.

Part of what keeps developers from testing more is friction. You have to pick a test suite, read the docs, learn the API, blow an hour or few chasing a bug because you misunderstood something, figure out the philosophy of it, rewrite your tests so they’re clear and paradigmatic…

The friction seems to be a lot higher in C/C++ than in dynamic languages. There are good technical reasons for it, but I think at least part of it is cultural. I’ve noticed a less testing in the Python community than Ruby, and I think that’s just because Rails was big on testing and has driven so much of the interest in Ruby. The community assumption is that software includes tests.

Updated to Rails 2.0.1

• rm’d lib/slash_urls.rb: Rails switched from ; to / to separate actions
• rm’d lib/resource_requirements.rb: now included in ActiveResources
• rm’d app/helpers/tags_helper.rb and gamers_helper.rb that had old controller names and were unused anyways
• app/controllers/gamers_controller.rb: documented and fixed raw post variable extraction
• updated post_path linkers in many views, controllers, and tests
• renamed discussion_anchor_post_path to anchor_discussion_post_path to match the new ordering for nested resource urls
• fix tag sorting on tag index
• move tags from /tags/Board+Games to /tags/Board_Games, as Rails fixed the bug that encoded ‘ ‘ as ‘+’ in non-get variable parts of the URL

The Details

The first two files I deleted were my patches to URL generation that Rails now includes. The next two helper files I never used, but had had old (singular noun) names.

The bit about documentation: the way to get at raw post variables changed, so I tweaked code and left myself a reminder of why I’m doing it (I had to look at the changelog, which means it wasn’t self-evident).

Nested resources (I have nested map.resources :discussions { |d| d.resources :posts }) changed from discussion_edit_post_url to edit_discussion_post_url, so there was a bunch of places to change that. The next change about anchor is me following this convention with my own convenience method.

Tag sorting on the index page was a bug that Snarky pointed out to me. When I made some performance tweaks to that page I forgot to keep sorting tags as they came out of the database. This arguably should’ve been a revision of its own as it’s unrelated to the upgrade, but it was an easy one-line bugfix so I let it in.

Last, I renamed the tag pages. The tag model’s to_param just returns self.name and Rails would turn “Board Games” into “Board+Games”. It’s common but technically incorrect, as + only means space in encoded GET/POST variables. The proper encoding of “Board%20Games” was really noisy, so I took a page from Wikipedia’s pagebook and use underscores instead, like “Board_Games”. Was one line in the to_param and one line in the controller’s load_tag before_filter, a dozen lines of tweaking old tests, and seven lines of new tests. Eeeeeasy.

The Verdict

Tests, tests, tests. If I didn’t have a solid test suite, I’d be noticing bugs two months from now in the least-frequently-exercised bits of code. Not only would I not have remembered to test some of the functionality, I wouldn’t have remembered the corner cases — or maybe I’d just have gotten bored of clicking through pages over and over and ignored the corner cases.

None of these were hard fixes and none were frustrating. I’d probably have finished even sooner if I hadn’t also been poking lolcats and chatting with friends. And now I have a big list of shiny new Rails 2.0 features I can put to work in NearbyGamers.

My thoughts: this is exactly backwards.

But I really liked the pages I read about automated testing and started putting that in practice almost immediately. Rather than sitting there and hitting reload and filling in forms and clicking buttons and waiting for pages and forgetting to check what happens when you leave half the form blank and… well, rather than all that error-prone tedium, I wrote code to test my code. And that’s great. It saves me from a lot of “oh yeah, I forgot that thing over there called this code” bugs.

I kept hearing about TDD, though. Books would mention it, blogs would tout it it. I guess it’s squirmed its way into my habits.

In the last few months of coding on NearbyGamers I’d hack at the models a bit, write some tests for them, and hey, as long as I’m writing tests, add some tests for the controller code I was about to build on top of that. And then maybe, after I implemented the basic feature, I’d write a test for an improvement and then tweak that code. In the last two weeks I’ve been writing code for the messages and forums and I just recognized that my tests have snuck in front of my code almost every time.

And it doesn’t feel backwards anymore. It just makes sense to think about my interface first, and to spend a minute pondering what sort of devious corner cases I can throw at it. I’m writing more tests, letting fewer bugs into production, and having more fun. I`ve broken the “Ehhh… it works, I’ll check it in and write some tests tomorrow” habit.

So this is my little bit of cheerleading for Test-Driven Development, a little more exposure for your unconscious mind to chew on.

I’m now a big fan of Mocha like I am of Rails. Ruby has a way of allowing coders to write magically polished libraries.