RSpec simplifies communications?

Eric PughMay 3, 2007

At CITcon, I learned a lot about RSpec, a Ruby library for writing out specifications that is used in BDD: Behavior Driven Development.

This has got me to thinking about one of the key challenges in software development: communciation. We spend massive amounts of time retelling requirements from one person to another, and translating them from one format to another. A Business Analyst writes up the requirements in a Word document. A developer translates those requirements into unit tests and code, and lastly a Tester verifies the functionality using yet another suite of testing tools! It’s no wonder so many software development projects suffer delays.

One of the key points that Martin Fowler made at CITcon was that he expected the roles of Business Analyst and Tester to merge, and the roles of Developer and Tester to merge. If you think about it, it makes sense. The Business Analyst knows best what the results should be, so shouldn’t that person be the one testing the code works correctly? And, the Developer is the one who knows (or should know!) what the weakest points in the code are, and so they should be best suited to test the code.

So what does merging roles have to do with RSpec? Easy, RSpec is currently the best lightweight way of writing specifications the way a Business Analyst might, that are runnable tests that a Tester might run. Now, I know that there are lots of ways of poking holes in this statement, but as a thought experiment, Rob, a colleague of mine, and I are going to attempt this, with me filling the role of the merged Business Analyst/Tester, and him as the developer. We need to write a bit of code for a shipping module for an ecommerce site that has somewhat unusual pricing rules. I have written some RSpec specifications that currently fail, and he’ll write the code until they pass. All without us communicating except via the specifications that I’ve written.

I ran rake spec:doc and produced this summary of the specifications I had written:

Shipping for non-combineable products
- should have the base price for just one
- should multiple linerarly the base price for more then one

Shipping for combineable product
- should have the base price, and extra fields filled in, but not used for just one
- should add shipping_factor_second to shipping base for two items
- should add shipping_factor_third to shipping_factor_second to shipping_base for three items
- should keep adding on the third_shipping_factor for any additional items beyond 3

shipping for multiple types of products
- should handle combinable and noncombinable products in same cart

Quite nice output from just pulling data out of some RSpec code, looks somewhat like what I would write as some requirements. I’ll be posting a followup on how Rob does with just those specifications to use in grokking my meaning!

More blog articles:

Let's do a project together!

We provide tailored search, discovery and analytics solutions using Solr and Elasticsearch. Learn more about our service offerings