Week 3, Day 1: RSpec, rspe, rsp, rs, r
This week kicked off with a splash, as our class dove into testing with RSpec. Over the weekend we immersed ourselves in RSpec lore, for many of us, encountering the testing framework for the first time. Luckily for me, it wasn't a completely new experience. I had done some RSpec previously through a SAAS course offered by UC Berkeley and in Hartl's Rails Tutorial. This was to come in handy, as my partner for the day had not done much of the reading. It seemed that we crawled through the assignments, as I spent considerable time to bring him up to speed on RSpec's syntax and conventions.
Test driven development with RSpec is like eating your vegetables. It's not pleasant (yet! -- and perhaps never), but it keeps your code healthy. For me and many of my classmates, it was important not to lose sight of that. We, as a rule, spent more energy setting up a test to ensure that a chunk of code did what it was supposed to do than writing the code itself. It feels tedious, no lie. It's like watering a root for days just to see a little sapling form for all your effort. But the long view is this: The sapling grows. And as that sapling thickens and reaches for the sky, it's the roots that give it its strength. It's the roots that allow it to expand and build on itself.
In terms of code, we strive to separate functionality into methods that do one thing only and do that one thing well. It's a good strategy on its own merits, for code clarity, and ease of debugging in PRY. The beauty of modular methods gets amplified even more though in the context of testing an application with a testing framework like RSpec. The ability to write tests against each individual method gives us peace of mind that we can expect those methods to work. With that assurance, we are free to build on top of them, grow that sapling into a hoary oak tree, and not live in fear that a change to our program will break existing code. If you expect your code to exist for the long haul and your application to grow in complexity, you can't afford not to test early and often.