On Fri, Apr 11, 2008 at 3:43 AM, 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...
Add one more 'me too' to the pile. I tend to use a directory named after the feature, with .story files inside breaking that feature into smaller chunks/paths through the application. Not real examples, but say, stories/shop/product_listing.story, shop/featured_products.story, etc. But if the story is simpler, and really just demonstrates basic crud functionality, that's exactly what I've been naming it: stories/users/crud.story walks through adding new users, viewing the index, viewing a user, editing them, and removing them. Anything that does more interesting work is then done separately (users/reports.story, perhaps), but often relies on the steps for users/crud to walk through the application and set up the data. Though, as mentioned in the other thread, sometimes I just use AR directly to create the right preconditions. Kyle _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
