rSpec and behavior driven development questions

Discussion in 'Ruby' started by gwtmp01@mac.com, Feb 5, 2007.

  1. Guest

    The rSpec tutorial (http://rspec.rubyforge.org/tutorials/stack_03.html)
    shows a new spec as:

    context "A stack with one item" do
    specify "should return top when you send it 'top'" do
    end
    end

    This empty context and empty spec 'passes', i.e. there are no failures
    to report.

    I don't pretend to be a TDD or BDD guru at all but in TDD
    documentation I've
    often seen the suggestion that a newly written test (i.e., a test for
    a feature or behavior that hasn't been implemented yet) should fail.
    You then implement the feature and know you have done so when the
    test passes.

    Two questions for any BDD or rSpec gurus:

    1) Why does the tutorial suggest a two step process of
    writing an empty spec, testing, and then going back and adding
    expectations,
    and finally testing again? Perhaps this is just because it is a
    tutorial?

    2) Why aren't specifications with no expectations flagged as
    'failures' by
    the rSpec test runner 'spec'?

    I've already been burned by the second situation where I put code in the
    specification but didn't actually call one of the expectation
    methods. I
    thought my implementation was matching the spec but in fact my spec had
    no expectations. It was impossible for the implementation to not meet
    the spec.


    Gary Wright
    , Feb 5, 2007
    #1
    1. Advertising

  2. On 2/4/07, <> wrote:
    > The rSpec tutorial (http://rspec.rubyforge.org/tutorials/stack_03.html)
    > shows a new spec as:
    >
    > context "A stack with one item" do
    > specify "should return top when you send it 'top'" do
    > end
    > end
    >
    > This empty context and empty spec 'passes', i.e. there are no failures
    > to report.
    >
    > I don't pretend to be a TDD or BDD guru at all but in TDD
    > documentation I've
    > often seen the suggestion that a newly written test (i.e., a test for
    > a feature or behavior that hasn't been implemented yet) should fail.
    > You then implement the feature and know you have done so when the
    > test passes.
    >
    > Two questions for any BDD or rSpec gurus:


    This should really go to the RSpec users list:
    http://rubyforge.org/mailman/listinfo/rspec-users

    But since you posted it here, I'll answer....

    >
    > 1) Why does the tutorial suggest a two step process of
    > writing an empty spec, testing, and then going back and adding
    > expectations,
    > and finally testing again? Perhaps this is just because it is a
    > tutorial?


    An important part of TDD is running the tests (specs) often. Same for
    BDD. When you're first learning, it is better to run them more often
    than less, so the tutorial stops to run them quite often.

    In practice, everybody that I've ever worked with begins to expand the
    distance between test runs as a matter of course. Eventually one
    pushes that envelope too far and finds themselves in an ugly
    headache-producing debugging session. At that point, it is helpful to
    be able to call up the discipline of baby-steps.

    > 2) Why aren't specifications with no expectations flagged as
    > 'failures' by
    > the rSpec test runner 'spec'?


    I don't know of any testing tool that flags empty test methods. Not
    saying there isn't one, but I've not come across it. They'll flag test
    classes (i.e. TestCase) with no test methods, but not empty methods.

    That said, we are looking at allowing you to explicitly identify
    unimplemented specs by excluding a block. So you would do this:

    context "today" do
    specify "should be a holiday"
    end

    Without the block, the output of a 'spec' run might be:

    today
    - should be a holiday (NOT IMPLEMENTED)

    This is not a definite at this point, but something we are considering.

    > I've already been burned by the second situation where I put code in the
    > specification but didn't actually call one of the expectation
    > methods. I
    > thought my implementation was matching the spec but in fact my spec had
    > no expectations. It was impossible for the implementation to not meet
    > the spec.


    I think this boils down to discipline. Let's say we did enforce a rule
    that specs with no expectations would fail. What's to stop you from
    doing this?

    specify "something important" do
    ...
    1.should == 1
    end

    Not only would that spec pass the rule, but if you did a quick glance
    through 100s of specs, you wouldn't even notice that it was doing
    something just to pass the rule.

    This may seem silly to you, but I've seen worse. As tools impose
    rules, developers under schedule crunches will come up w/ some pretty
    clever ways to fool the rules-checker.

    > Gary Wright


    Cheers,
    David
    David Chelimsky, Feb 5, 2007
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Shaguf
    Replies:
    0
    Views:
    792
    Shaguf
    Nov 28, 2008
  2. Mayank Srivastava
    Replies:
    1
    Views:
    94
    Brian Candler
    Mar 20, 2007
  3. David Chelimsky
    Replies:
    0
    Views:
    99
    David Chelimsky
    Sep 15, 2009
  4. David Chelimsky
    Replies:
    0
    Views:
    102
    David Chelimsky
    Oct 3, 2010
  5. David Chelimsky
    Replies:
    0
    Views:
    98
    David Chelimsky
    Oct 10, 2010
Loading...

Share This Page