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

aslak hellesoy aslak.hellesoy at gmail.com
Tue Oct 31 09:25:10 EST 2006


On 10/31/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 10/31/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > On 10/31/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > On 10/30/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).
> > >
> > > That may be its sweet spot, but BDD can be top to bottom proposition,
> > > and we'd like to support that in the long run.
> > >
> > > >But here in the office, we're also
> > > > beginning to find it useful for specifying GUI behavior.
> > >
> > > Sweet!
> > >
> > > > Of course, now that we're outside the original BDD roots of RSpec,
> > >
> > > We really need to talk about this!
> > >
> > > > 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?"
> > >
> > > Now you're talking!
> > >
> > > >
> > > > 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.
> > >
> > > How about this? We add a spec command option that allows you to set a
> > > series of one or more key/value pairs:
> > >
> > > -i or --include
> > >
> > > spec -i":lingua => 'português', :lingua => 'français'"
> > >
> > > That would run only specs or contexts set up like so:
> > >
> > > context "blah in portuguese", :lingua => 'português' do
> > > ...
> > > end
> > >
> > > context "..." do
> > >   specify "blah in french", :lingua => 'français' do
> > >     ...
> > >   end
> > > end
> > >
> > > This could be used for all sorts of suite organization, and can be
> > > automated through rake tasks.
> > >
> > > Sound like a good approach?
> > >
> >
> > Interesting, but it sounds somewhat redundant to the -s option.
>
> They are related, and maybe we can just add this capability to the -s
> option, but the key/value pair thing lets you group things together
> quite arbitrarily, while the -s option is based solely on the name of
> the context and/or spec. The arbitrary grouping allows you to separate
> the concern of how to organize specs vis a vis behaviour and other
> types of organization.
>
> A perfect example is our other thread about having certain specs run
> against the current rails release while others run against both the
> current release and edge-rails. We could solve the problem by wrapping
> the specs in conditionals, as you proposed earlier but I think that
> this feature would provide a simpler mechanism for doing the same
> thing. Not simpler inside rspec, but easier to use.
>

Agreed. Let's explore it post 0.7.0

Aslak

>
>
>
> >
> > > David
> > >
> > >
> > > >
> > > > Thanks in advance for your thoughts.
> > > >
> > > > Sincerely,
> > > >
> > > > Ian Dees
> > > > _______________________________________________
> > > > rspec-devel mailing list
> > > > rspec-devel at rubyforge.org
> > > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > > >
> > > _______________________________________________
> > > rspec-devel mailing list
> > > rspec-devel at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>


More information about the rspec-devel mailing list