2068837226

When I began learning Ruby on Rails two years ago, I actively avoided tests, and the topic of testing altogether.

I was eager to see my code ‘do stuff’, and skipped tests, contrary to the suggestions proposed in the holy grail of rails books — Michael Hartl’s Rails Tutorial. Writing extra code that didn’t seem to do anything was a very unattractive proposal.

Only after running several production systems, did I truly understand the value of testing. Let me explain that in practical terms:

  • If you find yourself repeatedly running the same commands in rails console, to check if something works … write a test.

  • If your users discover bugs in systems that used to work fine in the past … write a test.

  • If your code base is relatively stable, and your features are well defined … write a test.

Most Rails developers will probably throw a bunch of acronyms and jargon at you to convince you to write tests, but those three reasons I mentioned are all real circumstances that convinced me to write tests.

As far as testings frameworks go, it doesn’t matter. You don’t need rspec or cucumber, or whatever’s fancy right now. Ruby itself ships with tests of the box, and they work fine. (Test::Unit for your reference)

short version: Write tests when it’s obvious you need them.