rSpec and behavior driven development questions

[gwtmp01]

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

 

[David Chelimsky]

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