[Rspec-devel] What is a context?

David Chelimsky dchelimsky at gmail.com
Sun Jul 16 12:57:14 EDT 2006


On 7/16/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> David Chelimsky wrote:
>
> > 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
> > for.
>
> Hmm.. actually, looking at your controller example:
>
>
> > context "a new session" do
> > setup do
> > ...
> > end
> >
> > request :controller => :stories, :action => :new do
> > ...
> > end
> >
> > specify "should redirect to login action" do
> > ...
> > end
> >
> > specify "should render login page" do
> > ...
> > end
> >
> > end
>
> it makes me wonder if the simplest solution isn't just "in a controller
> spec, don't roll back between specifications".  Each context would still
> roll back, but within a context, you'd be able to keep pushing forward.
>
> In fact, I could see that as a generally useful tool, so it could be an
> option to context
>
> context "a new session", :rollback => false do
>   this
>   that
>   the other that depends on this
> end
>
> It might be useful in certain models, but the default would be "true"
> for models and "false" for controllers (taken care of by the generator
> script).
>
> Does that cause new problems?  It seems easier than events, and solves
> many of the problems.

The main problem it causes is philosophical. There is a guideline in
TDD (that we actually like) that tests (in this case specs) should not
depend on one another.

That said, this is something that could be very useful for scenario
testing. I think I'd rather come up w/ a different structure - one
that more explicit in stating that we're dealing w/ a sequence of
events. Something like this:

context "new session" do
  setup do
  end
  scenario "new user registration" do
    step "user navigates to registration page" do
    end
    step "user submits registration form" do
    end
  end
end

The problem I see is how this maps to expectations and how we print
out the documentation. As important as it is to have clear and DRY
ways to express different levels of specs, it is every bit as
important that the resulting docs are clear as well.


More information about the Rspec-devel mailing list