[rspec-users] Rspec Style

Curtis Schofield curtis at ram9.cc
Thu Aug 29 18:20:33 UTC 2013


My Question is about ordering of describes / context and the various styles
that people are using that deviate from .

Some context first:

Started TDD when i was a university researcher - as a way to do bug fixes
without regression.
Started using rspec in 2006 on the side and eventually switched over
completely by 2008.

I've seen alot of rails oriented rspec testing in the pattern (A)

describe Controller
  describe #method
    it "should"
    it "should not"

The 'context' keyword didn't come till later - it made a lot of sense to me
as I feel like objects are responsibilities that have contextual behaviors.

At some point in 2011 after doing outside in integration testing I started
to move away from describing '#method' first.

I know that there are tonnes of blog posts about a specific style of rspec
- when working at pivotal i saw a very general form pattern (A) above
frequently.

When the context keyword came out it gave me a handle on the feeling i was
having.

For the last few years in my rspec integration test and object tests i've
been following a pattern closer to this abstracted form pattern B:

describe Object
 context "with some precondition"
    it " has this behaviour"
    context " with some dependency "
      it " responds this way"

 context "under error conditions"
    it " has another behaviour"
    context " and some other state "
    it " has a different behaviour"


The pattern resolved to specific use case can look like this
for a controller:

describe Controller
   context "as a signed in user"
     context "with errors"
       context "#method"
         it "throws DidNotDoLaundryException"
       context "#method2"
     context "with correct input"
       context "#method"
         it " does the laundry"
   context "without a user"
     it " dances and falls over "

For a worker pattern - i usually use the specific interface as the main
call point
and break down the behaviors that it should have without binding my tests
to specific internal implementation -- as i might have done in unit-tests

I've noticed that a) I like to think about the responsibility of the object
first, b) the conditions required for the behavior c) the behaviour and the
very last thing i think of is the name of the method. I don't like
sprinkling method names around my spec files.

I agree that the documentation view that looks very uniform

Object
 #method
    should blah blah
    should not blah
 #method2
    when same something
      should blah blah
 #method3
    when same something
      should blah blah foo

is somewhat aesthetically appealing - but in my experience it has generally
left
much to be desired in terms of understanding the objects high level
responsibility
and often feels like i'm sprinkling the exact same context around the file
over and over again.


Has anyone else deviated from the standard pattern A ?





-- 
---
Modern Yoga vs Traditional Yoga
http://swamij.com/traditional-yoga.htm#swamirama
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20130829/ebc14071/attachment.html>


More information about the rspec-users mailing list