El 16/10/2007, a las 2:44, "Pat Maddox" <[EMAIL PROTECTED]> escribió:

>> Wincet Colaitua brings up a good point [3] in regards to  
>> StepMatchers:
>>
>>   "My main concern here is that you're now having to keep two  
>> files in
>>   sync to have the stories work properly."
>
> Perhaps there was some confusion with how I implemented that initial
> StepMatcher.  I've since explained that ultimately it should contain
> both the matching and mechanics.  Unless Wincent was referring to
> keeping the plain-text stories in sync with the StepMatchers.

Yep, that's what I was referring to.

If the conventions are kept reasonably tight then this concern could  
be largely ameliorated with a good automated tool for generating an  
".rb" file from an ".story" file, or updating an existing ".rb" file  
from an updated ".story" file.

So, for example, if the story file contained (excerpt only):

   Scenario: "foo bar baz"

The tool would generate a file with:

   Scenario "foo bar baz" do
   end

If the customer added another scenario and the tool was re-run, then  
another Scenario block would be added to the ".rb" file.

Now imagine that the programmer modifies the scenario in the ".rb" file:

   Scenario "foo bar ?" do |arg|
   end

Here I'm assuming that the whole matcher machinery you brought up is  
effectively handled behind the scenes by the Scenario module. The  
string basically defines a matcher (on the fly if need be) that uses  
a regex like this one, where "?" (or whatever symbol we choose; it  
could be "$baz", for example) has been replaced with ".+":

   /foo bar .+/

Ideally, the tool would be smart enough to recognize that the  
modified scenario in the ".rb" file corresponds to the one in the  
".story" file because:

   "foo bar baz"

Matches this regexp.

The tool would complain about cases where the ".rb" file had more  
scenarios than the ".story" file, listing the excess ones (this could  
happen if the customer deletes a scenario or modifies it enough that  
it no longer matches up.

I really think it's important that this thing, whatever it ends up  
looking like, be nice for programmers to use, not just programmer's  
customers.

Cheers,
Wincent


_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Reply via email to