Shouldn't developer tools be for developers first?
As (I believe) Jonas Nicklas pointed out in response to ThoughtBot’s post on integration testing, Cucumber is largely ineffectual in a project until you build up a library of domain-specific matchers and their respective code blocks.
What this represents is external domain-specific language design via regular expression.
The reasonable use of this is to facilitate the expression of desired behaviors by non-developers. For example, I have tell of organizations where QA people, for instance, write automated acceptance tests using Cucumber.
I share the Cucumber team’s belief that customer communication is essential. That’s facilitated, in Cucumber, by writing features in plain text (Gherkin). Cost is saved when issues are addressed in specs versus code – likely why the waterfall model was so popular at first. It’s just common sense.
It’s a form of risk management.
Every feature goes hand in hand with the risk that it will fail to be implemented to meet customer expectation. A risk becomes an issue, in this case, when a feature is implemented in a fashion differing from the customer’s expectation. The earlier that risk is mitigated, the less money/effort/time is wasted on the project handling risks that manifest into issues.
One way of mitigating that risk is to communicate to the customer how that feature will behave in the language of the customer’s domain.
Coulda solves the same problem. It has a rake task for marshaling the Feature, contained Scenarios, and all of the statements (Givens/Whens/Thens) into plain text.
However, Coulda shares many of the considerations Dan cites above:
- “Features” are just Test::Unit::TestCases
- “Scenarios” are just tests
- “Statements” (Given/When/Then) are just steps taken within a particular test
When I use Coulda on a project (I’ve used it on the job at this point), I don’t start with the intent of building a language. I know that I probably will, because I have, as my work progresses. I start by writing pending Features, pending Scenarios, pending Statements, and then I begin putting flesh on the bones. I refactor my tests. When I encounter duplication within a Feature, I Extract Method. When I encounter duplication across Features, I Extract Module (I’m guessing that’s in Ruby Refactoring but you likely get the intent: I create a module, move my method into the module, and include the module in my Coulda Features), and so on.
What bothers me so much about so many libraries, in general, is that they try to solve all of my problems.
That’s great but I don’t want that. Just like I don’t want to buy a car with a 500hp engine because I simply won’t need it. I just need a car.
So I kept Coulda simple. If you need more, great, then write it! If you find that you need the same thing repeatedly, great, make a new gem from it!
Automate what you need to do often. If you have an edge case, keep it out of your libraries, thank you! My brain has a hard enough time absorbing the ever-increasing size of the Rails API (and this from a guy who worked in J2EE hell for years).
Remember, these are the kinds of practices that gave us Rails. Don’t try to solve everyone’s problems. Focus on the frequently recurring problems. Scratch your own itch (I did!).
Posted by evan on Monday, January 04, 2010blog comments powered by Disqus