[rspec-users] it "should [action] ..." vs it with an active voice
dchelimsky at gmail.com
Mon Nov 12 20:22:18 EST 2007
On Nov 12, 2007 1:51 PM, Kyle Hargraves <philodespotos at gmail.com> wrote:
> On Nov 12, 2007 11:39 AM, Brian Takita <brian.takita at gmail.com> wrote:
> > Here are the main reasons that I prefer an active voice because:
> > * using it "should ..." over and over renders should meaningless (I
> > have grown this barely conscience aversion to the word 'should')
> > * less less words are needed
> > * the differentiating information of the 'it' statement is in the
> > front, rather than hidden behind should (space to the left is at a
> > premium)
> > * it describes what the software will do and what it does (both from
> > the Test Driven Design and Regression verification lifecycles of the
> > test)
> > * you still have a good "sentence template" that "should" provides
> > (you have to make a coherent sentence)
> > So here it my initial stab. Lets discuss :)
> I definitely agree that the active voice is nice in spec strings.
> A coworker, when he first saw the use of 'should', said something
> along the lines of "I thought you were writing specifications, not
Unfortunately, as we tried to get away from the word "test" and all
the baggage it brings along with it, we landed on another word,
"specification," which bears its own baggage.
In most cases, we are not writing specifications in the traditional
sense. Sure, we are specifying how our objects should behave, but that
notion changes daily as new requirements enter the system and we
mercilessly refactor. It's not the same kind of "specification."
> I fumbled and tried to explain that away, but the
> objection has stuck with me. I've also noticed on Rubinius' spec style
> guide that the use of should is discouraged:
That rationale seems a bit arbitrary to me. Why should there be
anything different between the doc strings and the code in the
examples? They're both talking about how the objects should behave.
Not how they do behave, but how we expect them to behave. The examples
can fail, in which case the objects are not behaving as they should,
nor are they behaving as the doc strings state that they unequivocally
*are* when you use imperative or active voice.
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
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.
All of this to say that I think "should" works well when what should
happen can (should???) change from time to time as we learn more about
> There are still some places that I use 'should'
What is the criteria for you? When would you choose "should" and when
would you choose active voice?
> 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.
> to 'it should have 4 entries'.
> (Though, in the code, the use of 'should' to express the expectation,
> does make sense, as the Rubinius page explains).
> Thanks for bringing this up, I'd been thinking about it lately.
Hear, hear! I have my not-so-subtle opinions about this, but I'm glad
to see the notion being challenged and look forward to other opinions.
More information about the rspec-users