[rspec-devel] Wider context for RSpec: GUI testing?

Ian Dees undees at gmail.com
Mon Oct 30 19:37:05 EST 2006

Hi, all.

I love RSpec's ease of expressing an author's desired behavior for
software.  That got me thinking about a little wider context (pun
unintended) for the meaning of "behavior."  It seems like the sweet
spot for RSpec is unit testing of Ruby classes (perhaps including
Rails models and controllers).  But here in the office, we're also
beginning to find it useful for specifying GUI behavior.

Of course, now that we're outside the original BDD roots of RSpec,
there are some philosophical questions, many of which boil down to,
"What's the best way of selectively enabling/disabling certain tests?"
where "best" means, "most RSpec-like?"

Let me give you two examples:

1) For localized applications, some tests might be written cleverly
enough to work in _any_ language build of the software, while other
tests might be language-specific (maybe they depend on a GUI element
having a certain caption, and its identity can't be deduced by any
other method).

2) Some GUI tests might require at least partial manual intervention;
it would be nice to skip these tests when running an overnight,
batch-mode test.

I can imagine a few different approaches in RSpec:

1) I could separate the tests into different files by my selection
criteria: put the English-only tests in their own file, or put the
partially manual tests in their own file.  The main downside here is
that sometimes the most logical way to group tests isn't necessarily
by language or degree of automation.

2) I could extend RSpec (thanks, Ruby!) to allow me to specify
optional criteria for a context, something like:

context "The Borfin", :interactive => :true do
  specify "should not go shlump after Mr. Bix un-shlumps it" do
    # drive the GUI and maybe prompt the tester to do physical stuff

3) Like #2 above, but for individual specifications instead of contexts.

I lean toward #2, but I wanted to bounce my question off the RSpec
devels, since the list archives reveal that you have been thinking a
great deal about the semantics of tests.

What I _don't_ want to do is pollute RSpec with a bunch of GUI testing
cruft.  It would be nice to use RSpec in this new domain without
compromising its simplicity in its primary domain.  Again, though,
that's where Ruby's open classes sure come in handy.

Thanks in advance for your thoughts.


Ian Dees

More information about the rspec-devel mailing list