Hi, I''m a little unhappy with how my stories are organised, and am wondering if anyone has found any particular method nicest. I''m working within an admin namespace, and currently have a plain text story file for each controller in the admin folder. I also have a steps subfolder, with one step file per controller. I''m thinking it would be nicer to add a little more granularity here, and to break the plain text story files down further into "actions" on each controller so there''s fewer stories per story file. This could be done either in the one folder, or by adding a bunch of subfolders. I figure this is pretty common though, and that there will be one or two approaches that have evolved to work pretty well? Cheers, Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20080411/86c8e197/attachment.html
On Thu, Apr 10, 2008 at 5:46 PM, Tim Haines <tmhaines at gmail.com> wrote:> Hi, > > I''m a little unhappy with how my stories are organised, and am wondering if > anyone has found any particular method nicest. I''m working within an admin > namespace, and currently have a plain text story file for each controller in > the admin folder. I also have a steps subfolder, with one step file per > controller. > > I''m thinking it would be nicer to add a little more granularity here, and to > break the plain text story files down further into "actions" on each > controller so there''s fewer stories per story file. This could be done > either in the one folder, or by adding a bunch of subfolders.I tend to have one story file per action, because one action is more or less an atomic unit of functionality. Pat
On Thu, Apr 10, 2008 at 8:46 PM, Tim Haines <tmhaines at gmail.com> wrote:> Hi, > > I''m a little unhappy with how my stories are organised, and am wondering > if anyone has found any particular method nicest. I''m working within an > admin namespace, and currently have a plain text story file for each > controller in the admin folder. I also have a steps subfolder, with one > step file per controller. > > I''m thinking it would be nicer to add a little more granularity here, and > to break the plain text story files down further into "actions" on each > controller so there''s fewer stories per story file. This could be done > either in the one folder, or by adding a bunch of subfolders. > > I figure this is pretty common though, and that there will be one or two > approaches that have evolved to work pretty well? >I organize my stories based on related behavior usually as defined by the customer. For example: - 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. -- Zach Dennis http://www.continuousthinking.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20080411/d2f1f77d/attachment.html
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/
On Fri, Apr 11, 2008 at 3:43 AM, Ashley Moran <ashley.moran at patchspace.co.uk> 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
On Apr 11, 2008, at 4:43 AM, Ashley Moran <ashley.moran at patchspace.co.uk> 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 UsersControllerI try not to think about what controllers I''m hitting in a story when thinking about the scenarios or steps. Clearly that comes up sooner or later, but it is secondary to the ''story'' expressed by the story. FWIW, David> 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
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 <ashley.moran at patchspace.co.uk> 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20080414/78cb48a7/attachment.html