aslak.hellesoy at gmail.com
Thu Aug 10 16:42:08 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.
My main gripe with specifications is the formal and general baggage
associated with the word. Almost mathematical proof-like. Design by
Contract is a way to *generally* specify contracts between objects.
It's more formal, and specification seems appropriate for DBC.
Let's assume that in order for something to be a specification, it has
to be general to some extent.
By this assumption I would argue that what we do with xUnit and RSpec
isn't really specifying. We're not stating something that needs to be
generally true. We're only giving descrete examples (hopefully lots of
them) of what it means for the software to be doing what it should.
This is the main reason why I'm starting to prefer example over specification.
> > == 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".
One of the holy grails of BDD is to bridge the gap between developers,
business analysts, customers and testers by providing a more ubiqutous
If you ask a customer or BA for a specification of what the software
should do, they're likely to come up with an exhaustive list of
acceptance criteria. Sometimes they will even cook up some acceptance
criteria that are so generic that it's hard and error-prone to
translate it into code. Consider the simple example of a Celcius to
Fahrenheit conversion program. If you ask for a specification, you're
likely to just get a mathematical formula. Then it's up to the
developers to translate that into descrete cases (examples) that can
This of course is a trivial example, but it illustrates my point of a
disconnect in form of what the customer wants and what the programmers
have to do in order to implement it.
Now consider the situation where you ask the customer/BA for examples
of valid temperature conversions. You're much more likely to get a set
of numbers that you can easily, with less risk of misinterpretation,
translate into code.
I think using example is key to making the requirements people express
what they need in a less ambiguous and easier translateble-to-code
format than if you ask for specs.
> > == 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 agree that used alone, it's pretty useless. However, if I ask
someone: "Can you give me some concrete examples of how the system
should behave", you'd be surprised how a lot of miscommunication and
misinterpretation just goes away.
> 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 don't think we *have* to change the name. With proper documentation
(perhaps a lingo translation cheatsheet) we can get people to use the
words we want. I should stress at this point that we're not trying to
get people to use new words just for the hell of it. We're trying to
change the way people *think* - including the people who define the
behaviour of software. Although I'm not well-read on
http://en.wikipedia.org/wiki/Sapir-Whorf_hypothesis I think there is a
lot of truth to it.
And even if we did decide to change RSpec's name to something else I
don't think it would be a big deal. It's still an underdog and there
are plenty of successful name changes (Switchtower => Capistrano is
one of them. EJBDoclet => XDoclet another one, hahaha)
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
More information about the Rspec-devel