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

aslak hellesoy aslak.hellesoy at gmail.com
Mon Oct 30 20:53:59 EST 2006


On 10/31/06, Ian Dees <undees at gmail.com> wrote:
> 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
>   end
> end
>
> 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.
>

A simple solution would be:

context ... do
  if(ENV['ENGLISH_SPECS'])
    specify "something that should only work in English mode" do
    end
  end
end

Or better:

context ... do
  if english?
    specify "something that should only work in English mode" do
    end
  end
end

-And define the english method in a spec_helper.rb (that you include
at the top of your spec) and contains the following:

class Spec::ContextEvalModule
  def english?
    !ENV['ENGLISH_SPECS'].nil?
  end
end

The turning it on is just a matter of defining a shell env var

Aslak

> Sincerely,
>
> Ian Dees
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>


More information about the rspec-devel mailing list