Today I’m going to start a series of blog posts surrounding the topic of testing. Specifically, I’ll be focusing on testing as it relates to writing Ruby on Rails apps. A quick Google search reveals a great many books have been published on the topic of testing. We’ve got Unit tests, Acceptance tests, Integration tests, and a host of others. Plus, we can’t leave out the various approaches to testing : Test Driven Development ( TDD ) and, of course its cousin, Behavior Driven Development ( BDD ). Starting down this road for the first time you’ll encounter terms like _ RSpec , Test-Unit , Spork or maybe _ Cucumber .
When I first approached Rails testing I was overwhelmed by the glut of information to digest. There seems to be a nomenclature that is deliberately esoteric. Rubyists do love their pet project names. Then you’ve got the syntactic nuances of each the different framework DSL ’s. It really is like drinking from the fire-hose if you’re new to Rails, or as was my case, new to testing all together.
This series of posts will by no means be a comprehensive study guide but aims to provide insight from the perspective of a developer navigating the quagmire of jargon that envelops Rails testing.
But first, a brief anecdote…
My family’s first computer was a Packard Bell 486sx-25. That’s right. 25 glorious Megahertz of raw execution power, 2MB of RAM , and a 40MB hard drive. I vividly remember spending many late nights installing new games or trying to optimize my file-system for performance. After all, how could I play Prince of Persia if my hard disk was fragmented?
It was all quite fun until the hard disk filled up. Being an industrious young fellow I read through my enormous DOS 6.2 manual and endeavored to solve my capacity issue by installing Microsoft DoubleSpace .
Ah, ha! Now I’m getting somewhere…
Unfortunately, as a 12-year-old kid I was unable to discern that DoubleSpace came pre-installed and no more space would be afforded me regardless of how many times I attempted to re-install. Being stubborn as I was naive I just kept trying, trying, trying until the inevitable Blue Screen of Death ( BSOD ) appeared.
Crap. I broke the family computer… again.
I was confident the problem was simply a lack of experience on my part and any qualified computer tech – maybe even the sales guy – at Montgomery Ward would be able to fix me up in a few minutes. But this time I was wrong.
After two hours of waiting for a quick fix we were told there was no recovering from the botched DoubleSpace. I had broken the family computer, lost all our files, and we were going home without a computer. The repair guys couldn’t fix it and it was squarely my fault.
I am so screwed…
Whether it was the grace of God or my mother’s exhaustion, the store manager took pity on us and, with 6 days remaining to our warranty, exchanged our broken PC for a new one. Oh sweet! , I thought to myself. But my mom was less enthusiastic about the situation and was concerned that I’d just destroy the next one in a few weeks and we’d be computer-less once more.
On the drive home my mother delivered an appropriate consequence for my recklessness and told me I’d lost computer privileges for the next month. “As a part of the family,” she lovingly scolded, “you can’t play with the computer like it’s your personal toy. We all would have lost the computer had things turned out differently.”
For a month? But how was I supposed to know that was going to happen?
Enter the value of testing…
We at HiringThing try to release new features on a regular basis. Naturally, with each new feature our codebase grows and the underlying complexity of our application grows as well.
We can never be assured of the quality of our product without being able to verify through testing that a change does not introduce a new bug. Just as I couldn’t have known the DoubleSpace scenario would have the outcome it did, software developers cannot account for every situation in which a bug might be introduced.
“ How was I supposed to know ” just isn’t acceptable. Better to test your code than test your users’ loyalty. In the coming weeks we’ll talk more about blind spots, the various testing frameworks for Rails, how to decipher the jargon, and answer any questions you may have.