I like this. It's pretty much one folder per stakeholder. If you have a question about a story or if a scenario starts failing, you immediately know who to ask whether it matters.
I'm more and more coming round to this model on an ideological level. It seems a more natural grouping (and more tangible) than "functional area" or "feature set". Having said that I don't use rspec in anger on my day-to-day projects so I am happy to defer to those who do. Cheers, Dan On 11/04/2008, Ashley Moran <[EMAIL PROTECTED]> wrote: > > > On 11 Apr 2008, at 05:16, Zach Dennis wrote: > > > - stories/ > > - projects/ > > - a_user_creating_a_project_story > > - a_project_manager_adding_users_to_a_project_story > > - admin/ > > - an_admin_removing_users_story > > > > I use stories as system level integration tests, so they usually > > cover a broader scope than a controller/action. > > > > > > Same here: I write all my stories from the point of view of a system > user trying to perform a task, with no regard for what code was being > executed to let them do so. In Zach's example, I imagine > a_project_manager_adding_users_to_a_project_story might touch > StoryController and UsersController if you go on to the user's page to > check that the project is on his list of users, etc... > > Ashley > > > -- > http://www.patchspace.co.uk/ > http://aviewfromafar.net/ > > > > > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
