[rspec-users] it "should [action] ..." vs it with an active voice

Pat Maddox pergesu at gmail.com
Mon Nov 12 21:09:34 EST 2007

I'm going to flip some of your stuff around, and hopefully I arrive at a point.

On Nov 12, 2007 5:22 PM, David Chelimsky <dchelimsky at gmail.com> wrote:
> On Nov 12, 2007 1:51 PM, Kyle Hargraves <philodespotos at gmail.com> wrote:
> > and if I'm working in
> > a project that tends to use it, I'll stick with it. But in my own
> > work, I prefer 'it has 4 entries'
> But it DOESN'T have 4 entries when you write that example. Then it
> does when you get the example to pass. But what if the example fails
> later on? The example says "it has 4 entries", but that is wrong. What
> is correct in that context is that it "should have 4 entries," but
> doesn't. And recognizing that gives you some flexibility to ask
> yourself whether the object is wrong, or the example is wrong. That
> was one of the motivating factors behind the choice of "should", and I
> personally find it quite compelling.

It probably doesn't matter much.  In fact, if you make an imperative
statement and the example fails, then the contradiction produces a
which is generally what you want with unit tests.


> Secondly, while the Rubinius team is using RSpec (which is great) and
> they are writing executable specifications (which is even greater!),
> writing a complete specification for an existing language is not
> really what BDD is all about. And so while they may be doing something
> akin to BDD, or the "language specification flavor" of BDD, it is
> really unrelated to the BDD process that the word "should" was chosen
> to support.
> The process I'm talking about is an iterative process. Not just
> iterative in terms of developing the software, but in terms of
> *discovering* requirements of the software as well. The idea is to be
> able to respond to change, to check assumptions, and to constantly
> redesign the system to align with the requirements as they are
> understood to be right at that moment.
> The Rubinius specs are a language specification. The team is not going
> to learn during iteration 27 that String#eql should return true for
> Strings that are the same except for one character. The spec is
> actually a *spec*. It'll take the CEO's signature to change it.

In BDD, the unit tests are not the final authority on how the system
should behave.  I think this is a fundamental difference from
traditional TDD.  If your specs are failing, that might suck, or it
might not.  It doesn't necessarily mean anything is broken.  Stories
are the final authority and let you know when something is broken.
But our specs are just a tool to help us design, and sometimes they
are a bit more useful by helping us localize issues.

(btw, I think that because of that, specs != unit tests.  They're very
similar, but I'll be so bold as to claim that there are no unit tests
in BDD)

So, in that sense, I think this ought to be the combination of
spec/story for the simple account withdrawal example:

Given my savings account balance is $100
And my cash account balance is $10
When I transfer $20
Then my savings account balance is $80
And my cash account balance is $30

(if you look at http://dannorth.net/2007/06/introducing-rbehave you'll
see that he uses "should be" for the Then clauses)

describe Account do
  before(:each) do
    @savings = Account.new 100
    @cash = Account.new 10

  it "should transfer $20 to another account" do
    @savings.transfer_to @cash, 20
    @savings.balance.should == 80

  it "accept a $20 transfer from another account" do
    @savings.transfer_to @cash, 20
    @cash.balance.should == 30

The description uses "should," thus is gentle and fluid.  If an
example fails, the developer can choose how to handle it however he

The story, on the other hand, must use imperative statements.  If it
fails, the developer must either fix the code so it passes, or have a
conversation with a customer if he feels the requirements may have

I hope I didn't muddle anything by using such a simple example.  In
fact I'm sort of hoping that it gets the point across better...under
the hood, the description and spec have virtually identical
implementations.  The difference is that the story is an authoritative
spec of how the system should behave, and the description has no
authority at all.


More information about the rspec-users mailing list