Newbq: Organizing your stories

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.

On Thu, Apr 10, 2008 at 5:46 PM, Tim H. [email protected] wrote:

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 H. [email protected] wrote:

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.

On 11 Apr 2008, at 05:16, Zach D. 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/

On Apr 11, 2008, at 4:43 AM, Ashley M.
[email protected] wrote:

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

I 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

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 Fri, Apr 11, 2008 at 3:43 AM, Ashley M.
[email protected] wrote:

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