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

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.