A short experience report regarding this thread: Early on when stories were introduced to rspec's code base I started using them, and I tried some different techniques to see what the sweet spot was for using stories in actual development. To do some of this I made modifications to rspec (this was before stories were released officially)
In my experience I found that trying to build up a highly re-usable set of steps caused a lot more overhead, both in the creation of new features and in the maintenance of ongoing development or changes to existing features. In practice has been much easier for me to build reusability in the form of helper methods which sit behind steps, and even to allow yourself to have very simple (even one line) step definitions. One problem I noticed I ran into was that I spent too much time trying to organize and group reusable sets of steps. This made it difficult when one story changed in how it did something, but another one did not, and it made my stories rely on several step files (ie: steps_for => [:site_navigation, :project_navigation, :project_creation, etc.]). Sometimes I would end up having to reorganize, or split one step into two, and then go find all places where things would be affected by this, etc. I also found that by focusing on this kind of step reusability I was writing much more granular stories (ie: implicit story style). When trying out what is now known as the declarative story style I have found that introducing new features and changing existing features takes much less time when all of my steps for a story are in as few as possible step files (typically just one step file). When I notice that two stories both have a scenario where the implementation of a step is the same, I pull that out into a helper much like David suggested. Now if one of those stories changes, you can change its step w/o affecting any others. In summary, don't focus on step reusability across stories, instead pull out helpers while allowing the steps to be defined separately for their respecive stories. This will make it easier to introduce new features and maintain/change existing features over the lifetime of the app. HTH, Zach On Fri, Jul 4, 2008 at 4:17 AM, David Salgado <[EMAIL PROTECTED]> wrote: > > Unless you're looking for the steps to show up when you run things, why not >> just have a helper method that does the setup for you and then have a Given >> step that invokes that method? >> >> I know I can extract logic into steps, but I'd like the pre-requisite >>> scenarios to have some assertions, and it doesn't feel right to put >>> assertions in steps (if that's possible). >>> >> >> I'm not sure understand this. Don't you have expectations (assertions) in >> all your Then steps? >> > > Sure. I was just hoping I could keep my prereq stuff as a story in its own > right - more for clarity when discussing requirements than for any other > reason. If it's just a step or a helper method, then that particular story > is reduced to a one-liner. I know I could always do both, and not be 100% > DRY, so I guess that's what I'll do. > > Thanks for the advice > > David > > > > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -- Zach Dennis http://www.continuousthinking.com
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
