I always sorta kinda did TDD. But not really. It never really clicked for me until several months ago and before that I didn’t even realize that it hadn’t clicked yet. The other day I wrote about pairing with Corey Haines and something that he said that really hit home: When I write my tests, I’m writing the code I wish I had. This almost forces you to write clean, well-designed code.
For example, if I know I need active products, and I start with the implementation, of course I’m going to call Product.find and pass whatever parameters I need to make that happen. But if I start with the test, I really don’t want to set all those expectations. I’d much rather stub a tiny method and check that I get the expected results.
But now I have another problem. I stubbed the model method, implemented the code in my controller, and have a fully-passing test suite, but my controller is calling a method that doesn’t even exist yet! That’s where the final piece of the TDD puzzle fell in place for me:
Cucumber is a Very Good Thing
Cucumber lets you create high-level tests that hit your entire stack. This means I can write a test that will hit an action as if it was a normal web request, and it will go through all the steps it would go through if it was serving it up to a normal browser (and depending on the engine you use, it may be). No stubs. A real request.
So my nice clean controller action that passes beautifully in rspec? Fails miserably in cucumber. Good!
It seemed strange at first to have two separate testing frameworks in my workflow, but once it clicked, it felt just right. Cucumber is what drives my features. Rspec is what drives my code. In other words, rspec is testing that my code does what it’s supposed to do at a nice, low, isolated level. Cucumber tests that my application is doing what it’s supposed to do at a nice, high, functional level.
Other Posts That Might Interest You
