Testing is a subject that is often talked about as a best practice in the Rails community. However, behind the scenes, many a Rubyist forego testing, using lack of time and “prototyping” as an excuse. The root cause is that a lot of Rubyist have bad habits that need to be broken, including myself.
Two years ago, when I started learning Rails, I was intrigued by its vast community, and the appeal of building apps rapidly. My intro to Rails, like many others was through online tutorials and blog posts. The problem with many of these blog posts and tutorials is that they skip over testing. By the time many newbies discover test first as a best practice, its often an afterthought and then implemented as so. And this was my story.
As a learning project, I’ve decided to put together a guide to Rails testing for a number of reasons. First, I wanted to create this guide to personnally instill a habit of testing first for future projects. Secondly, I wanted to obtain a better understanding, deeper knowledge, and experience of testing first, with the hopes of making testing first more fun and less of a chore. This guide will be broken up into a series of blog posts over the next couple of weeks. This week, I’ll explore the importance of testing first from seasoned Rubyists.
Learning from the Experts: Why Bosses Test First
When asked why they test first, whether TDD (test driven development) or BDD (behavior driven development), this is how fellow Rubyist responded…
“It is mostly about design, behavior, and staying in line with the important/correct features for me. Reliability and regression tests are certainly nice.” –@gustin
“The TDD workflow helps me get into my programming groove. I even like to leave a failing test in my feature branch when I head home so that I know exactly where to start again the next day.” –@tsaleh
“TDD at the unit level help drive good object oriented design by making bad designs painful to mock and test.” –@tsaleh
“BDD ensures that the behavior of your application is documented in a living fashion – retroactive documentation takes time and quickly becomes stagnant if it’s not tied to a test ensuring behavior.” –@rbxbx
“Because customers yell at me when I test after shipping.” -Jeff
Being Practical about Testing
Testing is the verification of the application’s requirements. Writing a failing test before development can help ensure requirements are being met. A simple analogy: you’re building a coffee table and need four legs measuring 30″ each. You have planks each measuring 48″. Would you cut the wood first, and then measure to verify that they met the 30″ requirement? It may seem quicker to get started by just eyeballing it. But there is a high probability that you’ll end up wasting more time and resources. And it’s the same with your code.
Hadiyah Mujhid 