[rspec-users] The problem with learning RSpec

Ben Mabey ben at benmabey.com
Thu Jun 18 13:36:25 EDT 2009

Bill Kocik wrote:
> Just to add a couple cents in...
> I've been working as either a sysadmin or software developer for the
> last 10 years (software development pretty much exclusively for the
> last 5 or 6). I started picking up Rails about 2 years ago, and though
> I was always aware of TDD - and even occasionally dabbled in it - I
> never really embraced it. Not because I didn't see its importance, but
> because the barrier to entry always seemed too high, and schedules
> never allowed for it (as a friend of mine is fond of saying, "You mean
> we don't have time to do it right, but we have time to do it over and
> over again?").
> Right now I'm working on a personal project for which I have no QA
> team to watch my back, so instead I'm doggedly using top-down BDD with
> Cucumber (and unit tests) to help keep me in line. I think the biggest
> hurdle to learning it is this: Pretty much all the tutorials and docs
> written on the topic center around some simple example app that's easy
> to test. But in the real world, software is messy, and tends to resist
> being tested. I know the traditional counter argument is that this
> means your design is flawed, but that isn't always true. One of the
> biggest challenges I faced was how to test authentication in my
> application, in which users sign in using their Twitter credentials
> via OAuth[1]. Another was in testing my own endpoints that create JSON
> that's rendered via JS in the browser[2]. Maybe Selenium could have
> helped here, but creating tests in general was already slowing me to
> the point that I'm a good deal behind schedule, and I couldn't take
> another day or so to learn how to use Selenium with the risk that it
> might not really suit my situation for one reason or another - because
> software is messy.
> One that I haven't tackled yet but will have to soon is how to test
> code that runs as a BackgrounDRb worker.
> I came up with solutions for all of this (except for the BDRb stuff),
> but I'm not entirely sure of their quality. They certainly feel
> hackish, but I can't put my finger on why. I suspect David Chelimsky
> or Ben Mabey or Aslak or any of a hundred or more other people could
> have come up with beautiful, elegant solutions
I'm flattered, but FWIW I am always struggling on how best to test 
things as well.  In cases like you are describing it seems like testing 
it is often harder than the actual implementation.  Making those tests 
valuable without being too brittle can be challenging.

>  to the challenges I
> faced, but since none of them were standing over my shoulder I have no
> way of knowing, and none of this is covered in the
> write-a-blog-in-10-minutes Rails demo.
> That has been my challenge in learning and using BDD.
Thanks for sharing Bill.  I totally understand where you are coming 
from.  IME, it is hard when writing a tutorial or giving a presentation 
to not teach to the least common denominator in the audience (the 
beginner).  Time constraints usually set in too that don't allow you to 
do more advanced topics that would require more explanation.  Thats why 
for most presentations I try to focus more on the process and ideas 
rather than the example and tools (i.e stuff you can't learn from a wiki 
so easily).  I do see your point however.  I often feel frustrated in 
other presentations at the simplicity of examples given and wish for 
more in-depth and challenging examples.  Your point is noted: a good 
tutorial app for BDD should involve harder to test components (web 
services, asynchronous messaging/processing, caching, etc) since this is 
what pops up in real projects.
> [1] My solution: http://tr.im/oW8y
This is more or less how I would of done this with Cucumber.  And you 
were complaining about no advanced tutorials. ;)  Nice writeup.

> [2] I defined these two custom steps (JSON_CALLBACK is defined as the
> :callback arg I pass in my 'render :json' calls - but it will trip the
> JSON parser if its there):
> Then /^I should get valid JSON$/ do
>   assert_nothing_raised do
>     assert JSON.parse(@response.body.gsub(/^#{JSON_CALLBACK}\((.*)\)/, '\1'))
>   end
> end
> Then /^I should find "(.+)" in JSON/ do |xpath|
>   json_hash = JSON.parse(@response.body.gsub(/^#{JSON_CALLBACK}\((.*)\)/, '\1'))
>   xmldoc = Nokogiri::XML(json_hash.to_xml)
>   xpath.gsub!('_', '-') # in XML, underscores will be dashes.
>   xpath = "./hash" + xpath unless xpath =~ /^\/\//
>   assert !xmldoc.xpath(xpath).blank?
> end

I probably would of done this in RSpec instead of Cucumber.  Then I 
would manually tested in a browser.. since you are going to want to do 
that anyways.  I take this stance quite a bit as I feel adding Selenium 
(or another automated browser solution) can potentially add much more of 
a maintenance burden than webrat in :rails mode.


More information about the rspec-users mailing list