El 15/10/2007, a las 17:01, "David Chelimsky" <[EMAIL PROTECTED]>
escribió:
> Part of this is to separate the programming 'noise' from the text, so
> if we do head down this path (which remains to be seen) I doubt these
> would end up in the same file.
Thinking about this, the only way to really know how all this will
work is to try it out. That is, we can speculate about what users
will do depending on what kind of "interface" we give them, but to
really find out the only way will be to actually put it into practice.
But having to trial these two possibilities isn't as onerous as it
may sound. You see, if you want to separate the "noise" from the
story then you're going to need to "compile" it into an intermediate
form anyway. That is, you might start with "source" file, "stories/
foo.story", that looks like:
Story: ...
Scenario: ...
Given: ...
When: ...
Then: ...
But you'll need to "compile" that into something executable at some
point anyway (probably "stories/foo.rb", or, if you prefer, in a
subdirectory):
Story "..." do
Scenario "..." do
etc...
The programmer then fleshes out the "rb" file, working in a way very
similar to how he/she can work today with describe/it blocks,
starting with the skeleton and gradually adding the block bodies.
If the customer updates the story file then the corresponding Ruby
file should be updated too. I personally hate this kind of fragile
dependency, but it may be a necessary evil. Doing it manually is
error-prone, and I suppose this could be done in an automated fashion
but the tool for doing it would necessarily be relatively "dumb";
rigorously parsing Ruby is a non-trivial task, so the parser would
have to be "fuzzy", and I guess that makes that approach error-prone
too. But it seems an inevitable consequence of having non-executable
stories.
Developing a little bit the idea I previously posted, rather than
defining StepMatchers explicitly in this Ruby file it would probably
be nice if the programmer could just write something like:
Given /\A(.+) navigates to (.+)\z/ do |args|
login_as args[0]
get args[1]
end
In other words, that the whole StepMatcher thing be effectively
encapsulated behind the Given, When, Then classes. For a line in the
story file like this:
Given: "admin navigates to user list"
We could start out with a basic skeletal Ruby implementation like this:
# "admin navigates to user list"
Given /admin navigates to user list/
And the programmer then customizes the regex and provides a body. The
comment is just a possible idea, so that you can see which story line
the regex was originally based on even after you've customized the
regex.
The other thought which occurred to me was that RSpec itself really
has two groups of "customers". The developers who use RSpec are one
group, and the developers' customers is the other. If this idea works
then we can provide a developer-friendly interface (.rb files) and a
friendly-to-non-developers interface as well (.story files).
Anyway, just some ideas that I wanted to throw out there.
Cheers,
Wincent
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
