[
http://jira.codehaus.org/browse/JBEHAVE-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143549#action_143549
]
Elizabeth Keogh commented on JBEHAVE-123:
-----------------------------------------
I'd wait - the thing is slowly disappearing anyway as we move to a
tell-don't-ask structure. The next step will be to pass the reporter into the
runner, which will probably have to happen as we decide whether to break on
pending or just truly broken steps, and change the output of the reporter
accordingly.
So, hold up :) It served well as an interim measure for some very messy code.
> JBehave configuration classes
> -----------------------------
>
> Key: JBEHAVE-123
> URL: http://jira.codehaus.org/browse/JBEHAVE-123
> Project: JBehave
> Issue Type: New Feature
> Reporter: Elizabeth Keogh
> Assignee: Elizabeth Keogh
> Fix For: 2.0
>
>
> I'm starting to find that there are multiple different things I might want to
> do, and the dependency injection mechanism isn't really working as well as
> I'd like for this.
> It would be nice to produce a configuration that's easy to set up, and use
> that for everything. We could then have different ways of configuring
> JBehave, eg: environment-driven, settable, null (so you have to specify
> everything yourself), etc.
> Going to have a play with this, driving it using the "broken scenarios only".
> BTW, every time I get a "broken scenario" or "error output" story, I'm
> driving it by actually breaking a story. You won't see these broken stories
> checked into the build, but it's easy enough to replicate yourself!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
