January 2011 Archives

Cucumber vs Steak (vs WTF?!)

After reading Cucumber vs Steak, I found myself overwhelmed with feeling—at times experiencing violent agreement, rage, and simple dumbfoundedness.

Violent agreement

The tools are here to serve us and not the other way around. Quite so.

Descriptions matter. Oh, yes. In order, I focus on describing the feature, understanding why I need the feature (maybe I don’t), and then describe the steps that I need to perform, as the actor, to exercise the feature.

Not using “web_steps”? Awesome. The less that I have to remember at any given time to do my job the more effective I am.


Yet, testing Cucumber with Rails requires that I have at least three files available at any given time (and often four or more): the feature, the steps, and the impl — sometimes paths.rb.

Why do I need this separation? I don’t. In fact, personally, it pisses me off. Instead of (just) complaining about it, I wrote Coulda. I understand that not everyone wants to see their fake English (it’s call-by-regexp, folks) next to their code. I also hear there are folks that don’t like wearing deodorant too.

You want complexity? Try looking at the implementation of RSpec or Cucumber.

Simple dumbfoundedness

All we’re discussing here are RSpec and family? No love for all of the other alternatives out there? Really?

Monocultures die, folks. They are inherently vulnerable to significant change. We need more variety and less cargo culting (oh, shit, I said it!) in Ruby-land.

As a general rule, if a tool’s implementation hurts my puny brain then I don’t want to use it. Why? I’m staking the future of a project on tools written by other people. What if I run into a bug? The source is open but I damn well better be able to understand the problem. Otherwise, I’m waiting for Joe Gem-author for a fix. Beyond that, if I can’t understand a gem’s implementation then I’m limited in the ability to personalize the tool for my uses—to really make it my own.

The biggest reason to use Cucumber is that “[t]here are no implementation details here. No following links, no filling in fields, no pressing buttons”? Cucumber prevents me from writing fake English describing click links, filling in fields, and pressing buttons? That little gherkin must have some awesome trance-like effects. Pass it over this way!

But, seriously, the tool doesn’t steer me one way or the other. I like my step descriptions to actually describe what the actor is doing and not the actor’s intent. I leave that stuff for the Feature name, the “in_order_to”, “as_a”, and “i_want_to” (again, using Coulda instead of smoking those psychoactive cukes). If Cucumber is primarily a tool for communicating then isn’t helpful to tell people who are just reading your English (because they don’t have multiple files open) what you’re actually doing in a step? In Coulda, I do that anyway; it helps me visualize the UI a litle better in case I don’t have a visual design already (a whole different topic of discussion waiting to be had there).

Cutting to the chase

This is bigger than just “how do you eat your Reese’s Peanut Butter cup” where by “eating” I mean “TDD/BDD” and “Reese’s Peanut Butter cup” I mean “code”.

This started with complexity. There’s too damn much of it.

We’re becoming a bit like Java. Our tools are getting more complex. And, eventually, that complexity is going to bite us in the ass. Hard.

Me? I’m sticking to my *::Unit (MiniTest rocks!), thank you (and rewriting Coulda to hurt my pathetic brain less). Beyond that, I’m trying to be picky about which tools I let into my stack.

And I’ll be on my soapbox about this at DCRUG and Mountain West Ruby Conf 2011.

Posted by evan on Jan 31, 2011