Home > Articles > Programming > General Programming/Other Languages

Becoming a Software Developer Part 2: Test Driven Development with Ruby

  • Print
  • + Share This
Developers can become more productive and spend a lot less time debugging code by creating Extreme Programming style unit tests before the rest of the code is written. Every "Ruby nuby" should learn about test-driven development and create unit tests.
Pete McBreen is the author of Software Craftsmanship: The New Imperative (Addison-Wesley, 2001, ISBN 0-201-73386-2). Software Craftsmanship is the winner of the Productivity Award for Software Development magazine's 12th Annual Jolt Awards (see http://www.sdmagazine.com/jolts/).
From the author of

Introduction

Once you've taken your first steps as a "Ruby nuby", you're ready to start thinking about how to write software that works. Software development is simultaneously both very simple and extraordinarily complex. It's simple because every line of code we write is easy to read and understand, but it's complex because the interactions between all the lines of code give the software its interesting behavior.

As you'll have discovered if you played around with the toy Odometer example from my last article, it's very easy to make a mistake when coding. That example was tiny; it only had three classes and less than 100 lines of code. Imagine the grief you could have working on a small application, say 5,000 lines of code, and then scaling up that fun factor as you realize that commercial applications often contain 50,000 to 500,000 lines of code (though some are much, much bigger). When applications get to be that size, verifying that the code works becomes a major challenge.

Obviously, someone will have to test the overall application once you've managed to get parts of it working, but getting large enough parts of it working for someone to test it is difficult. Yes, you can use the traditional design and code reviews to have other pairs of eyes look for mistakes, and you can try stepping through the code in a debugger to see what's really happening, but there's a much better way: test-driven development.

  • + Share This
  • 🔖 Save To Your Account