I’m starting to use lighthouse (http://llighthouseapp.com) for my
projects at work. I’m organizing iterations as milestones and stories
as tickets tagged to a milestone.
Lighthouse offers an API so that you can write access the data in your
account and write apps to process that data.
I think you see where this is going.
It seems to me that a plain text story could be stored in a lighthouse
ticket, read in via the lighthouse API … AND EXECUTED BY STORY
RUNNER.
Call me crazy
Sure, this is theoretical in terms of lighthouse - but it reveals an
important benefit of plain text stories: it would be possible to
express stories in any of a variety of systems and have them consumed
by an adapter that feeds them in to story runner.
account and write apps to process that data.
important benefit of plain text stories: it would be possible to
express stories in any of a variety of systems and have them consumed
by an adapter that feeds them in to story runner.
wow, and maybe some day, you could press a button to generate a
screencast of a story…
(almost not kidding…)
Actually you can already do better than a screencast using tools like
watir and selenium which actually run tests against the app in a
browser (so you can see it happening).
Definitely. I sort of hold up the value of plain-text stories as
self-evident, but this example illustrates why they’re so valuable.
Basically, anywhere you could ever want to express requirements
(email, ticket system, wiki, whatever), you can do so, and the result
is executable. That’s mind-boggling to me.
That’s really cool – i’d look to do the same with Pivotal Labs’
Tracker – export my stories and run them directly. The problem of
course is acceptance - what happens if someone changes a story in a
ticket? how do you easily track/manage that?
That truly would be the “holy grail”. Before this whole discussion of
plain text stories came up I was playing around with the idea of
creating an app for story collaboration between developers and
customers. So developers and customers alike would login to the system
and create, modify, and comment (I was think Django Book styling
commenting) on stories. I think this would facilitate discussions of
stories between developers and customers who don’t have the luxury of
always working at the same location. There are of course many other
benefits of a system like this for teams that are on site- it would
create living documenation that would evolve with the project, and
versioning would provide a window on past iterations. The other benefit
would be to have helpers in the app that would explain to customers what
a story is exactly, and maybe have wizards on creating a story (so a
step process going though scenarios, and the different clauses like
given, when, etc.)
I was thinking that the app would then generate the skeleton of the
story file for the developer to work with. What I was having hard time
solving was updating the stories based off of modified stories. This
problem was touched on the step matchers thread when someone thought
that the plain text stories would generates the “real” story testing
code. But having the stories being truly plain text based would get rid
of this problem and allow such a story collaboration app to be created
and be very straightforward to do.
For this reason I would love to see something like plain text stories
happen. The stories could be pulled from such an app and be ran just
like your suggesting they could be pulled from lighthouse.
It seems to me that a plain text story could be stored in a lighthouse
ticket, read in via the lighthouse API … AND EXECUTED BY STORY
RUNNER.
Not crazy at all. I’ve seen fancy systems (IIRC, RallyDev is one) that
integrate automation testing with bug tracking/feature requests, so that
a bug doesn’t truly become closed until its tests pass. Naturally, that
was only supported if you were using a certain IDE, a certain language,
a certain test framework, etc.
On Wed, Oct 17, 2007 at 09:41:27AM -0500, David C. wrote:
Thoughts?
I think it will be really useful if you start changing issue status
based on the outcome of the run stories. My main beef with issue
trackers has always been just that, that users click a box to say that
something is done instead of it being handled automatically.
/Marcus
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
