[Rspec-devel] What is a context?

David Chelimsky dchelimsky at gmail.com
Sun Jul 16 11:08:22 EDT 2006

On 7/16/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> David Chelimsky wrote:
> >
> > context and specify work well for class level use cases, but It does
> > occur to me that there is room for some other structures for higher
> > level specs that a customer might understand. Maybe context and
> > specify are enough. Thoughts?
> I've been wondering about this while writing rails specs.  For my model,
> I end up with specs like
> An otherwise valid receipt
> - should start out valid
> - should disallow an empty vendor field
> - should disallow future purchases
> - should allow an empty image
> So, as you say, that maps well.  But when I get into the controller
> specs, they start looking funnier:
> The ReceiptController
> - should be a ReceiptController
> To create a receipt,
> - get the new receipt form
> - post a good receipt
> - post a bad receipt
> Elsewhere in the receipts controller,
> - check the receipts list
> Some of the specs are more like task-lists.  Many of the actual specs
> are now buried down at the should-be level, where they aren't seen in
> the specdoc.  I can't push them up to the specification level, or else I
> end up with specs depending on other specs - and each spec is executed
> in a fully-rolled-back context with transactional fixtures, so that
> doesn't work.

Great observations Jay. I think the problem is that the rspec DSL
works really well for specifying behaviour of an individual object,
while controller specs, as they currently work, are sub-system level
integration tests.

If you think about the built-in rails functional testing, it's really
got its own DSL that is separate from that provided for "unit" and
"integration" tests.

So probably what we need in rspec_on_rails is a custom DSL - not only
at the expectations level (i.e. response.should_blah) but at the
structural level as well:

context "a new session" do
setup do

request :controller => :stories, :action => :new do

specify "should redirect to login action" do

specify "should render login page" do


> The simplest solution would be to allow the "shoulds" to optionally
> appear in the specdoc.  I'm not sure what a more complex solution would
> look like.

We talked about that some months ago. The problem is that the code
doesn't always know how far up the call stack to look for the target

@target.should_equal expected_value
@target.property.should_equal expected_value

It also complicates the structure a bit. Right now we've got
context/specify. To support expectations generating their own
reporting we'd probably want context/event/expectations. Then the
above example might look more like this:

context "a new session" do
  setup do

  event :request, :controller => :stories, :action => :new do
    response.should_redirect_to :login


which could output:

given a new session
- when a request is received for 'stories/new'
  - the response should be a redirect to login

>From what I've seen, JBehave works more like this. You define
contexts, events and expectations in their own classes. Then you
define behaviours by stringing them together. It might be a bit more
DRY than what we've got, but it also means you have to look in a few
different places to understand a failure. Whereas rspec pushes you to
keep ALL of the context within a single context.

Some people on the list have requested nested contexts and we've been
resistant because we want to encourage clarity in specs. However,
perhaps events could be the intermediate structure that we're looking



More information about the Rspec-devel mailing list