If youâve done some Rubyâeven a little bitâyou have probably heard of test-driven development (TDD). Many advocates present this software practice as the âsecret keyâ to programming success. However, itâs still a lot of work to convince people that writing tests that are often longer than their implementation code can actually lower the total time spent on a project and increase overall efficiency.
In my work, Iâve found most of the claims about the benefits of TDD to be true. My code is better because I write tests that document the expected behaviors of my software while verifying that my code is meeting its requirements. By writing automated tests, I can be sure that once I narrow down the source of a bug and fix it, itâll never resurface without me knowing right away. Because my tests are automated, I can hand my code off to others and mechanically assert my expectations, which does more for me than a handwritten specification ever could do.
However, the important thing to take home from this is that automated testing is really no different than what we did before we discovered it. If youâve ever tried to narrow down a bug with a print statement based on a conditional, youâve already written a primitive form of automated testing:
if foo != "blah" puts "I expected 'blah' but foo contains #{foo}" end
If youâve ever written an example to verify that a bug exists in an earlier version of code, but not in a later one, youâve written something not at all far from the sorts of things youâll write through TDD. The only difference is that one-off examples do not adequately account for the problems that can arise during integration with other modules. This problem can become huge, and is one that unit testing frameworks handle quite well.
Even if you already know a bit about testing and have been using it in your work, you might still feel like it doesnât come naturally. You write tests because you see the long-term benefits, but you usually write your code first. It takes you a while to write your tests, because it seems like the code you wrote is difficult to pin down behavior-wise. In the end, testing becomes a necessary evil. You appreciate the safety net, but except for when you fall, youâd rather just focus on keeping your balance and moving forward.
Masterful Rubyists will tell you otherwise, and for good reason. Testing may be hard, but it truly does make your job of writing software easier. This chapter will show you how to integrate automated testing into your workflow, without forcing you to relearn the troubleshooting skills youâve already acquired. By making use of the best practices discussed here, youâll be able to more easily see the merits of TDD in your own work.
Ruby provides a unit testing framework in its standard library called minitest/unit. This library provides a user-level compatibility layer with the popular test/unit library, which has been fairly standard in the Ruby community for some time now. There are significant differences between the minitest/unit and test/unit implementations, but as we wonât be building low-level extensions in this chapter, you can assume that the code here will work in both minitest/unit and test/unit without modification.
For what itâs worth, I donât have a very strong preference when it
comes to testing frameworks. I am using the Test::Unit
API here because it is part of
standard Ruby, and because it is fundamentally easy to hack on and extend.
Many of the existing alternative testing frameworks are built on top of
Test::Unit
, and you will almost
certainly need to have a working knowledge of it as a Ruby developer.
However, if youâve been working with a noncompatible framework such as
RSpec, thereâs nothing wrong with
that. The ideas here should be mostly portable to your framework of
choice.
And now we can move on. Before digging into the nuts and bolts of writing tests, weâll examine what it means for code to be easily testable, by looking at some real examples.
Get Ruby Best Practices now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.