El 15/10/2007, a las 14:21, “David C.” [email protected]
Given an employee
When employee has worked 2 months
Then employee should accrue 1 days vacation time
And as far as requirements go the leading whitespace could be treated
as totally optional (because you can rest assured that people will
get it wrong, use tabs instead of spaces, or spaces instead of tabs,
or mix them up etc).
- The developer then writes custom “step matchers”; where do they go?
TBD. Probably in a directory under stories named steps or
My main concern here is that you’re now having to keep two files in
sync to have the stories work properly. The great thing about the
Story Runner in its current form (and RSpec too) is that you can
start off by writing a skeleton using a natural-language-like Ruby
DSL, and then you flesh it out with code to fulfill its purpose. In
other words, turn on code folding and a non-programmer can read it
out loud and know what it means; turn off code folding and a
programmer can see what’s happening inside. It’s great because your
spec files are both readable by all and executable by the computer!
But if your stories are stored in separate files, you no longer have
that. If you edit the story you have to regenerate the story’s
specification in a way that preserves existing changes. Discrepancies
between the files will break the stories. And on top of this you have
to worry about a third place, the place where you define your step
matchers (unless you define them in your “implementation” file, but
you’re still having to worry about two files then). So I am a little
worried about this becoming very cumbersome and error-prone compared
to the rest of RSpec.
If I understand the proposals correctly then this will be great for
non-programmer customers, but for programmers it will actually be
awkward and uncomfortable, which would be a shame because one of
RSpec’s great selling points is that it makes TDD/BDD pleasant.
I can’t help but thinking that the best solution will be of the form:
Story “…” do
Scenario “…” do
Given “…” do; end
And “…” do; end
When “…” do; end
Then “…” do; end
Where, whatever the format ends up being, the customer knows that the
user-editable bits are the ones between the quotes, and the bits
between “do” and “end” are for the programmer. I thought the proposal
to have “strings like $this one” wasn’t bad.
at which point ‘admin’ and ‘the user list’ would be extracted and
thrown at the block.
Obviously there are pieces missing here, but I think that this could
prove very easy to use.
I’d rather see:
matcher = StepMatcher.new “$user navigates to $path” do |args|
Where StepMatcher can easily translate:
“$user navigates to $path”
into a regex like:
/\A([^ ])+ navigates to ([^ ]+)\z/
But I’d be even happier if this weren’t stored in a separate file and
were just part of the story file:
When “$user navigates to $path” do |args|
Thanks for taking the time to explain all this, David!
(And on a side note: I recently switched to the digest version of the
mailing list, so I am aware that these replies aren’t showing up as
continuations of existing threads… sorry about that! Does anyone
know of a way to avoid this when replying to the digest?)