On 10/15/07, James Hughes <[EMAIL PROTECTED]> wrote: > On 10/15/07, Wincent Colaiuta <[EMAIL PROTECTED]> wrote: > > 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. > > +1
I think what we're proposing would be nice for programmers. Right now we have stories that look like this: http://pastie.caboo.se/107589 This is from the BDD talk we did at RailsConfEU. Now on the one hand, we have readable strings and good reuse of steps. But on the other hand, there is simply no way to look at that file and instantly grok this: Story: Plan cup As a cup organizer I want to declare how many teams are in the cup So that I can lay out the chart Scenario: set up a 4 team cup structure Given a new cup with max teams of 4 When I ask to see it Then It should have a row count of 3 And The round 1 row should have a column count of 4 And The round 2 row should have a column count of 2 And The winner row should have a column count of 1 Scenario: set up an 8 team cup structure Given a new cup with max teams of 8 When I ask to see it Then It should have a row count of 4 And The round 1 row should have a column count of 8 And The round 2 row should have a column count of 4 And The round 3 row should have a column count of 2 And The winner row should have a column count of 1 Of course, this would be more readable: Story: Plan cup As a cup organizer I want to declare how many teams are in the cup So that I can lay out the chart Scenario: set up a 4 team cup structure Given a new cup with room for 4 teams When I ask to see the chart Then the chart should have 3 rows And the 1st row should have 4 columns And the 2nd row should have 2 columns And the 3rd row should have 1 column Scenario: set up an 8 team cup structure Given a new cup with room for 4 teams When I ask to see the chart Then the chart should have 4 rows And the 1st row should have 8 columns And the 2nd row should have 4 columns And the 3rd row should have 2 column And the 4th row should have 1 column There are a few things to note here. 1st: The pastie'd version is the result of not having mid-string variable values. 2nd: Things like "Then It" (w/ the 2nd word capitalized) were the result of us not seeing things in a unified way. Lastly, code that intermingles different levels of abstraction is harder to read than code which maintains a consistent level of abstraction. You wouldn't want to see a method like this: def save validate_attributes prepare_connection exec("insert into things (name, ...) values ('#{name}', ...)") end For the same reason, it is difficult to read the second scenario in the pastie. We get all excited that we get to reuse steps from the first scenario, but the sad truth is that the result is not easy to read, and is therefore not all that friendly to anyone, developers and customers alike. Separating the abstract representation of the steps from their detailed implementation is a worthwhile goal because it makes things more readable, which implicitly makes things more developer-friendly. Of course, that doesn't necessarily lead us straight to plain text, but at the very least we'd want block-less steps in scenarios. Cheers, David _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
