kidkonia blogs

I've never been a fan of unit testing. I didn't get the point. Why would I write code that looks at the results of this test or that function when that's what I need to be doing? My tests consisted of starting up my application and then navigating my way to the feature that needed demonstration.

But then I started Zombies! 2, and it ended up changing everything. It was on this project that I got lazy; I didn't feel like booting up IRB every time I modified the Human class so I could test & look at the new limb removal system or whatever it was that changed. So I decided to offload it and write my first-ever unit test.

Now, what exactly is one of these "unit tests"? It's exactly what it sounds like: a test that runs over just one part, or unit, of software. In this case, it was the Zombies::Human class that was being tested, just one part of the whole Zombies module. If you look at the code for test/human.rb, it runs through what I would normally have done by hand:

• Creates a new object
• Runs a few methods; in this case:
  • Damage a forearm
  • Chop off an arm
  • Chop off a lower leg
• Display the status of the object

As I went along, I added more and more to this test (it started with just the create & damage phases, since the recursion didn't work). I would inspect the object dump at the end to make sure everything worked. Once the test passed without issues, I just looked for the "OK" at the end. If I changed the file, I would re-run the test and make sure everything was okay then, too. If anything failed, it got fixed. Just a once-over that helped to prevent bugs further down the line.

And now the rest of the project follows suite. I've fleshed out the test/ directory to have them for the map parser, the human class, and all the parts of the Zombies::Game class individually. Basically, it just made life easier.

One thing you'll notice is that I didn't use Unit::Test or any other fancy framework. All I did was isolate my process (display a name, run code, display "OK") and automate what didn't change. The result? A simple, 7-line framework that does everything I need it to: bin/test.

For those wondering, here's what it provides:

• test(name) { block } A simple function that just wraps a bit of code. It displays the given message, a "...", and then runs the code. If nothing comes up, the "OK" is tacked on to the end.
• assert(test [, message]) Raises an exception (StandardError with the given message) if the test is false