David C. wrote:
Agreed. Tools is tools. Process is process. (boat is boat …)
And parts is parts. Let’s not forget that:
Jay
On Aug 24, 2008, at 12:31 PM, David C. wrote:
In terms of the feature (which is the report), I see this as just
another scenario.In terms of driving development and estimating effort, I see this as a
new User Story.Does this clarify or further confuse?
I see your scenario of 499 registrants as a new feature of the
existing story 
On Aug 24, 2008, at 4:18 PM, Jay L. wrote:
David C. wrote:
Agreed. Tools is tools. Process is process. (boat is boat …)
And parts is parts. Let’s not forget that:
Wendy's Commercial - Parts is Parts - YouTube
Jay
OT, reminds me of when, a while back, I was developing CAD software,
and had a potential customer call who told me (with a strong Boston
accent)
their company designs pots.
“Oh, neat, what kind of pots, you mean cooking pots?” I asked.
“No, no,” she replied, "machine ‘pots’ "
Needless to say, I didnt win the client 
On Aug 25, 2008, at 11:19 AM, aslak hellesoy wrote:
new User Story.
In light of what David and I have said previously, I would express it
exactly the other way around:“The scenarios in this user story describe an expansion of the
existing feature.”In other words, the story (and its scenarios) are inputs to the
development. The output is a fatter feature.Aslak
Aslak, so in terms of the cucumber runner and BDD development
process, where would you add the scenario? reopen an existing .story
file?
On Mon, Aug 25, 2008 at 5:12 PM, Jonathan L.
[email protected] wrote:
I see your scenario of 499 registrants as a new feature of the existing
story
In light of what David and I have said previously, I would express it
exactly the other way around:
“The scenarios in this user story describe an expansion of the
existing feature.”
In other words, the story (and its scenarios) are inputs to the
development. The output is a fatter feature.
Aslak
On Mon, Aug 25, 2008 at 5:37 PM, Jonathan L.
[email protected] wrote:
Aslak, so in terms of the cucumber runner and BDD development process, where
would you add the scenario? reopen an existing .story file?
Yes, add it to an existing .feature file (or create a new one if the
story’s scenario don’t fit in an existing feature).
Aslak
As the author of the original scenario runner, if Aslak has come up with
a
nicer implementation - both in terms of design and hackability - then I
say
chuck my one out and use his
As long as it is an easy adjustment (i.e. transparent or with an easy
migration) for users of the current scenario runner then I think we
should
ship it in.
Cheers,
Dan
2008/8/20 Pat M. [email protected]
On Thu, Aug 21, 2008 at 6:08 PM, Joseph W. [email protected]
wrote:
Hello,
I’ve been looking through the cucumber documentation and have a couple
of questions.
Hi, Sorry for the late reply,
I’m curious which of the disadvantages you list would be impossible/very
difficult in the classic story runner. I’m just trying to envisage if
From GitHub: Let’s build from here · GitHub - 10 means big
effort, 1 small. Relatively. Your opinion may differ.
5: Hard to get started with. A special "all.rb" file must be
written before it can be used.
3: No out of the box Rake support, which puts a lot of people off.
3: No i18n, so if you want to write stories in a different
language than English you’re out of luck.
8: Poor error reporting. No way to know on what line a plain text
story failed during execution or parsing.
1: Limited colouring of output.
5: No simple way to execute only one scenario.
8: No command line tool to run stories.
2: No easy before or after hooks.
5: No highlighting of step parameters in the output
2: No detection of ambiguous step names
Cucumber and the classic story runner where to co-exist what would the
Cucumber plugin be able to do that the classic story runner could never
I assume that by plugin you mean Rails plugin? (Cucumber is a
standalone library that may be used as a Rails plugin).
realistically hope to achieve.
The Story runner could achieve this if someone put enough effort into
it. That would have to be someone other than me, because I don’t have
the time (or desire) to do it. Let’s say it’s up for grabs.
Also looking at one of your disadvantages:
- ‘Limited colouring of output’
I’ve been playing around with patches here and there to improve the
colour of the classic story runner formatters. Do you still see
limitations in this as it is in edge?
That’s one of the easiest things to fix, and also one of the smallest
disadvantages IMO.
My final question is about the Rspec book. I’ve no idea when this will
be released or what pressures there are on publish deadlines. How much
would this effect a move to Cucumber (avoiding having redundant story
examples in the book when we all use Cucumber)?
Regarding the book - we haven’t decided whether or not to cover
Cucumber.
In any case, writing stories/features for the Story runner will be
almost identical to Cucumber features.
On Tuesday I ported one of our projects at work over to Cucumber. Over
1000 steps. I ended up having to change almost nothing in the text or
step defs (except for resolving some duplicates and ambiguities that
Cucumber complains about where RSR says nothing). I have written up
what I did and will post it to the Cucumber wiki next week when I have
some time to proofread it.
Cheers,
Aslak
At the risk of being a bit controversial…
2008/8/24 David C. [email protected]
[…]
Sadly, “spec” has just as much baggage, if not more, as “test” does.
These days we’re calling these things “code examples,” (tongue
pressing into cheek) so maybe we should change the name to
rcodeexample?
Or rbehave?
The rbehave.org domain is available (I registered it some time ago), and
rspec has naturally evolved from its original goal of code-level specs
to
become a full-stack behaviour description framework.
Just a thought.
With regard to the stories and features thing, I see a BDD-shaped story
as
providing a context - and justification - for a feature:
As a [stakeholder]
*I want [a feature]
*So that [I get some benefit]
Before we started using this structure, a “story” would often just be
the
middle line, so it wasn’t immediately obvious who the stakeholder was or
why
they wanted the feature, which in turn would often lead to over-work,
under-work or just plain wrong-work. Of course the word “story” has its
own
baggage. In XP a story is “a placeholder/promise for a conversation”,
and as
such could just be a title scribbled on a card. I wrote the story
articlehttp://dannorth.net/whats-in-a-storyto put this all in
context - if you ask 5 agile folks what a story is, you
will likely get 6 answers.
I agree that the feature is the interesting thing, and also that there
may
be several stories about the same feature in different broad contexts.
In
any event the scenarios provide the definition of “Done” for the
feature,
which is kind of the whole point. So I guess I’m saying I’m ambivalent
about
the story/feature distinction. I don’t look at stories as work units as
much
as a more formal description of (some aspect of) a feature.
After speaking with Aslak - and some FDD folks I met at Agile 2008 - I
can
fully agree with organising stories by feature. In fact in Peter Coad’s
FDD
they have features within feature sets, within subject areas, which
might
well map to stories within features within [not sure - subject areas?
themes? something broader anyway]. FDD features seem to be “thinner”
than
what I understand Aslak’s description of features to be.
One thing that makes me happy is that we seem to have consensus around
the
word “scenario” - which is where the outside-in work really starts.
Cheers,
Dan
2008-08-30 17:02, Matt W.:
RuBehave
Now that’s cool! I love it!
On 29 Aug 2008, at 19:37, Dan N. wrote:
ago), and rspec has naturally evolved from its original goal of
code-level specs to become a full-stack behaviour description
framework.
or RubyDD
or RuBehave
I actually really like calling them specs rather than tests, at a
unit-testing level. It makes a real difference to me that I’m
expressing a specification for the class I’m about to code - it
makes it much more natural to do it before you write the
implementation when it’s a spec rather than a test.
cheers,
Matt
On 30 Aug 2008, at 19:31, Scott T. wrote:
Scott
One of the main adoption barriers we had with rspec at the BBC was
the uniquely British problem of ‘rspec’ sounding, to the uninitiated,
rather too much like ‘arse peck’.
On Aug 30, 2008, at 2:12 PM, Tero T. wrote:
2008-08-30 17:02, Matt W.:
RuBehave
Now that’s cool! I love it!
Personally, I always liked the rbehave / rspec combo, of Mike Myers &
Ali G.
Scott
On Fri, Aug 29, 2008 at 1:37 PM, Dan N. [email protected] wrote:
At the risk of being a bit controversial…
2008/8/24 David C. [email protected]
[…]Sadly, “spec” has just as much baggage, if not more, as “test” does.
These days we’re calling these things “code examples,” (tongue
pressing into cheek) so maybe we should change the name to
rcodeexample?
I was really only joking.
Or rbehave?
The rbehave.org domain is available (I registered it some time ago), and
rspec has naturally evolved from its original goal of code-level specs to
become a full-stack behaviour description framework.
I think we’re not at the point where we can really play with the name
of the code-level framework. Changing rspec’s name would impact a lot
of people. Consider the following:
- RubySpec uses MSpec, based on RSpec.
- Ruby itself runs its build against RubySpec.
- NetBeans supports RSpec.
- TextMate’s official bundle repo includes an RSpec bundle.
- Numerous open source projects use rspec for code examples.
- Including many rails plugins, so rails apps are depending on
plugins that depend on rspec.
I’m not saying it’s something that should never happen. But we’re in a
time right now (IMO) where it’s both too late and too early to do it.
Too late because of wide usage and momentum. Too early because a) it’s
not deeply ingrained enough quite yet for users to accept the burden
of the name change and b) we don’t really have the
team/infrastructure/support system to make it an easy transition.
middle line, so it wasn’t immediately obvious who the stakeholder was or why
which is kind of the whole point. So I guess I’m saying I’m ambivalent about
the story/feature distinction. I don’t look at stories as work units as much
as a more formal description of (some aspect of) a feature.After speaking with Aslak - and some FDD folks I met at Agile 2008 - I can
fully agree with organising stories by feature.
Stories? Do you mean scenarios?
In fact in Peter Coad’s FDD
they have features within feature sets, within subject areas, which might
well map to stories within features within [not sure - subject areas?
themes? something broader anyway]. FDD features seem to be “thinner” than
what I understand Aslak’s description of features to be.
It seems that there is no word that is baggage-free. I think that
trying to think of this in terms of FDD would just add more confusion.
I do like Feature, in part, because it refers to the system. User
Stories are about how a user uses the system, where as a Feature is
about how the system responds to use. So Features are about system
behaviour. Maybe we should just go back to where we started, and call
these things (Stories/Features) … ahem … Behaviours. It’s a
thought.
One thing that makes me happy is that we seem to have consensus around the
word “scenario” - which is where the outside-in work really starts.
Agreed. Stories and/or Features seem to be more about organization and
communication. Scenarios drive code development.
FWIW,
David
On Sun, Aug 31, 2008 at 6:56 AM, Matt W. [email protected] wrote:
Personally, I always liked the rbehave / rspec combo, of Mike Myers & Ali
G.Scott
One of the main adoption barriers we had with rspec at the BBC was the
uniquely British problem of ‘rspec’ sounding, to the uninitiated, rather too
much like ‘arse peck’.
I think that could be resolved with a CI-driven contraption that you
keep in your back pocket and gives you a little peck whenever the
build fails. WDYT?
On Aug 31, 2008, at 7:56 AM, Matt W. wrote:
Personally, I always liked the rbehave / rspec combo, of Mike
Myers & Ali G.Scott
One of the main adoption barriers we had with rspec at the BBC was
the uniquely British problem of ‘rspec’ sounding, to the
uninitiated, rather too much like ‘arse peck’.
with cucumber? ouch!
On Sun, Aug 31, 2008 at 9:02 AM, Jonathan L.
[email protected] wrote:
On Aug 31, 2008, at 9:39 AM, David C. wrote:
Agreed. Stories and/or Features seem to be more about organization and
communication. Scenarios drive code development.+1
I also like to organize them into workflows, tasks, goals
Which makes me think maybe the scenario should be a more independent,
reusable item
We’ve talked about a tagging scheme that would allow you run scenarios
in any logical combinations, but unless we want to go to
one-scenario-per-file (which I, personally, don’t), we still need a
default organization scheme.
WDYT?
On Aug 31, 2008, at 9:39 AM, David C. wrote:
Agreed. Stories and/or Features seem to be more about organization and
communication. Scenarios drive code development.
+1
I also like to organize them into workflows, tasks, goals
Which makes me think maybe the scenario should be a more independent,
reusable item
I find pronouncing the R with a piratey ‘arrrrr spec’ helps avoid any
arse or peck embarrassment.
I’m still struggling with how to pronounce rspec in Japanese.
The best I’ve managed is ‘l spec’
All these darn r’s
Joseph W.
http://www.joesniff.co.uk
Matt W. wrote:
On 30 Aug 2008, at 19:31, Scott T. wrote:
Scott
One of the main adoption barriers we had with rspec at the BBC was
the uniquely British problem of ‘rspec’ sounding, to the uninitiated,
rather too much like ‘arse peck’.
On Thu, Sep 4, 2008 at 3:37 PM, Rick DeNatale [email protected]
wrote:
Personally, I always liked the rbehave / rspec combo, of Mike Myers & Ali
G.
I lost the beginning of this thread…
A crude migration guide is available here:
Aslak