Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add pretty formatter #57

Closed
wants to merge 1 commit into from
Closed

Add pretty formatter #57

wants to merge 1 commit into from

Conversation

renier
Copy link

@renier renier commented Apr 10, 2012

This adds a pretty formatter to cucumber-js. It makes some changes to the Core API to enable traversing from the feature object down to the steps with their step results. Tests for this are in another commit that will be part of another pull request.

@jbpros
Copy link
Member

jbpros commented Apr 10, 2012

Thank you Renier.

I'd like to keep the AST (abstract syntax tree) decoupled from the execution, the results and therefore keep it stateless. What I mean by that is the execution results are not supposed to be stored on AST objects. In other terms, a tree should be able to be visited (executed) more than once.

Practically, Cucumber.Ast.Step should know nothing about StepResult objects.

Let's do some BDD here ... :)

Outcome: The formatter should be able to display the step name/contents related to a step result, when it receives one.

Context: Step results currently have no link to their parent step.

Actions/Options:

  1. As a step result event always follow its step event, the formatter could store the current step and build a step/result pair to a local map when the result event is caught. This is easy but the day we introduce parallel scenario execution (if we do someday :)) things will go wrong.
  2. Accept the step object as a parameter to SupportCode.StepDefinition#invoke() and attach the step to the step result when it's instantiated. This would be robust and it makes a lot of sense, IMO.

WDYT?

@renier
Copy link
Author

renier commented Apr 13, 2012

Hi Julien,

I think that the AST objects remembering the last result for that object, if there was any, does not prevent the tree from being executed/visited more than once.

However, I see nothing wrong with your proposal of instead feeding the AST object into the step result. I'll have to look at the code again with that idea in mind and see if there are any problems. If not, it should not be hard to refactor.

@jbpros
Copy link
Member

jbpros commented Apr 13, 2012

Hi Renier,

I'm almost done implementing the second solution. 6b58ca2

I'll finish that today I think.

jbpros added a commit that referenced this pull request Apr 13, 2012
- The parent step is now available on all types of step results
- Step results "inherit" from a base step result object (extraction refactoring)
@jbpros
Copy link
Member

jbpros commented Apr 13, 2012

@renier you can now call stepResult.getStep() on any kind of step result.

@renier renier closed this Apr 17, 2012
@lock
Copy link

lock bot commented Oct 25, 2018

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Oct 25, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants