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
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
