dchelimsky at gmail.com
Thu Aug 10 04:35:38 EDT 2006
On 8/10/06, Luke Redpath <luke at agileevolved.com> wrote:
> > Here is my take on some of them
> > == Spec ==
> > Pro: Fits well with the RSpec name
> > Con: Not so easy to 'talk' about
> > Con: Doesn't underline the Behavioural gist of BDD
> Whilst I still find myself using the T word out of habit, I'm trying
> to get into the habit of using the word spec - I like it. It goes
> hand in hand with RSpec (which I also like the sound of), I can say
> that I'm "speccing" my code/app and I have no problem with "running
> my specs". It also keeps to the notion of executable specifications.
The problem w/ using "spec" is that specifications tend to be more
general, and often supply examples:
A savings account should apply interest on the last day of the month
based on an average daily balance for that calendar month.
For example, given a savings account with $100 on January 1st, no
additional deposits in January, at an interest rate of 5%, then the
balance should be $100 on January 30th.
Given the same account and the same conditions, the balance should be
$100.42 on January 31st.
In this case, you couldn't really have an rspec spec/example that
expressed the spec:
context "A savings account" do
specify "should apply interest on the last day of the month based on
an average daily balance for that calendar month" do
You could, however, expess the individual examples:
context "a savings account with $100 on January 1st, no additional
deposits in January, at an interest rate of 5%" do
specify "should have a balance of $100 on Jan 30" do
specify "should have a balance of $100.42 on Jan 31" do
That make sense?
> > == Example ==
> > Pro: Easy to talk about
> > Con: Doesn't fit with the RSpec name
> > Con: doesn't fit with BDD lingo
> I just don't like the word example used in this context. To me the
> word example has to many other uses/connotations to make it worth
> considering. It sounds silly to me to talk about your code "examples".
This is subjective. For me, "examples" is so general that it really
doesn't carry the same baggage as "spec", "scenario" or "test". I'm
sure we'll find many different opinions on this.
> > == Behaviour ==
> > Pro: Fits with the BDD lingo
> > Con: May be hard to talk about in some situations / with some people
> > Con: Doesn't fit the RSpec name
> This is a lot better than example but it doesn't roll off the tongue
> like the word spec does.
> I'm certainly not keen on the idea of changing RSpec's name. I like
> the name, I'm always trying to plug it on forums/IRC chat etc. and
> changing the name now would just make the job of promoting RSpec
> harder. It will confuse people who have vaguely heard of RSpec but
> haven't got around to using it yet IMO.
I have mixed feelings about this. On the one hand, I agree that the
name wouldn't need to change regardless of the underlying
nomenclature. We can still talk about rspec as being a tool we use to
express (and automate the execution of) concrete examples of
On the other hand, rspec is presented to the world as BDD framework,
but BDD is not about specifications. It's about discovering and
automating the execution of acceptance criteria in the form of
concrete examples of specifications (sound familiar?). It's about
providing a common vocabulary for project owners, developers and
testers. Using this common language, the project owner gets to define
acceptance criteria. Using the same vocabulary, testers then know
precisely what to test and developers know precisely what to develop.
The "it's not about testing" mantra is still true, but only at the
point that you sit down to write some code. When we're using examples
to drive the code, thinking about the behaviour helps us to write more
clear, useful examples and more flexible structures in our code. For
project owners and testers, its still all about testing.
Anyhow, I digress. The point being that perhaps the "spec" in "rspec"
carries the same baggage that "test" in "rtest" might. True, there is
some name recognition as you suggest. It is catchy. And I don't think
we've seen any good alternative candidates yet. On the other hand,
this is still its infancy, and I think it's too early for us to feel
trapped by the name. So I'd like to leave the floor open for
suggestions. We might not come up with anything more suitable. But
then again we might.
Thanks for reading :)
More information about the Rspec-devel