[Rspec-devel] Given,Then,When

aslak hellesoy aslak.hellesoy at gmail.com
Fri Aug 11 09:08:08 EDT 2006

On 8/10/06, Alvin Schur <aschur1 at telus.net> wrote:
> Is it reasonable to say that the Given, Then, When is able to describe
> everything we need?

It's Given When Then. (Given, Then, When is David's fault ;-)

The GWT format started as a general format for User Story acceptance
criteria (used by agile teams). -Written on 3x5 index cards and put on
an story wall. It's great for this purpose because it's terse and very

In the spirit of the ubiqutous language idea from Eric Evans' Domain
Driven Design book, early BDDers experimented with adopting this
format in code. See http://jbehave.codehaus.org/ In JBehave, Given
When Then are first class constructs.

> Is it reasonable to say that Context, Specify is able to describe everything
> we need?

Perhaps. But we're not only trying to describe everything we need.

We're also trying to get customers, business analysts, testers and
programmers to speak the same language.

User Story acceptance criteria usually get translated into
tests/specs. Context/Specify is not a format that is well suited for
User Story acceptance criteria, and this is the main reason we're
exploring other alternatives/words. We don't want to do the
translation because it's error prone and time consuming.

Whatever we end up with, we'll try very hard to make the
context/specify style be backwards compatible.

> If not, will rSpec allow users to define their own terminology suitable for
> their domain?

Sure! It's Ruby. Just put a require 'spec_helper' in the top of your
spec, and monkey-patch or alias the methods you want.

> Is internationalization allowed?
> contexte, specifique; and if I could find the accent aigu it would look like
> French.

Malheureusement pas. Inside RSpec, context and specify are method
definitions, and Ruby doesn't allow accents here.

> Changing terminology from "test" to "specification" changes thought processes,
> but does it change the underlying semantics or implementation?

Implementation of what? RSpec never used "test"


> Thanks,
> Alvin.
> On Thursday 10 August 2006 11:41, Chris Anderson wrote:
> > Specrs,
> >
> > I haven't been mailing the list much, but I have been using rSpec in
> > some projects and for fun. Most of the discussion about name-change /
> > syntax changes has been unexciting to me, but this stuff really seems
> > to hit the nail on the head. Not only does it clean up the
> > documentation side of things, if it were implemented correctly it
> > could cut down on a lot of setup code dupliction. I'm imagining
> > calling out to shared methods in the "given" blocks, so that common
> > elements of setup can be shared. I think this works because of the
> > addition of the "when" block, which really makes clear the event
> > central to defining the behaviour being focussed on in this "spec".
> >
> > Granted, there is still more to work out in this syntax (eg multiple
> > given/when/then blocks to specify a deck of cards, etc.)
> >
> > Hmm... I'm still liking specify - it connotes writing your specs first.
> >
> > Alot to think about. My two cents as an rSpec user: I'd just like the
> > framework to be stable soon. If I were confident that the specs I
> > write now will be useful for the life of my project, I'd probably stop
> > using test:unit altogether.
> >
> > RSpec,
> > Chris
> >
> > On 8/9/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > Fellow rspec'ers:
> > >
> > > One thing lacking in the current rspec syntax is direct support of the
> > > BDD triad: Given,When,Then. Right now, rspec supports Given in the
> > > form of contexts and combines When and Then in specify blocks. This
> > > lends itself well to structural aspects of the code we're specifying
> > > (i.e. "A standard deck of cards should have 52 cards", but does not do
> > > a good job of separating out events (When) from expected outcomes
> > > (Then).
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel

More information about the Rspec-devel mailing list