sittercity/gocumber

Define and execute gherkin steps in Go

gocumber's Issues

Report line numbers for failed steps in scenarios

Currently gocumber does not report the line of the feature that caused the failure. Currently it reports the line number of the step that caused the failure. This can lead to problems if a step if used in multiple features. Example:

% godep go test ./
--- FAIL: TestRecipientFeature (0.01s)
        Location:       broadcast_recipient_feature_test.go:257
        Error:          Not equal: "Invalid push address" (expected)
                                != "Invalid recipient email address" (actual)

--- FAIL: TestReadJobHandler (0.00s)
        Location:       read_job_feature_test.go:106
        Error:          Not equal: "the-push-id" (expected)
                                != "" (actual)

--- FAIL: TestReceiveJobHandler (0.00s)
        gocumber.go:131: Undefined step:
                And the following Broadcast Tasks should be created for that Broadcast Job:
        gocumber.go:131: Undefined step:
                Given the following Templates exist:
        gocumber.go:131: Undefined step:
                And a Recipient exists with the following data:
        gocumber.go:131: Undefined step:
                Then I should receive a reference to the created Broadcast Job
FAIL
FAIL    github.com/sittercity/broadcast-center  0.045s
godep: go exit status 1

We should match what cucumber does in reporting failures for features:

Failing Scenarios:
cucumber features/tagulicious.feature:4
cucumber features/tagulicious.feature:8
cucumber features/tagulicious.feature:12

Incorrect processing of Outline examples

I am not sure I am understanding how the outline examples are processed. Based on my understanding we are not processing them correctly. Let me provide an example. For this gherkin:

Feature: Scenario Outline with DocString

Scenario Outline: Something
  Given something is:
    """
    <how> functional <really_though>
    """

Examples: 
  | how         | really_though    |
  | minimally | barely                |
  | incredibly | overwhelmingly |

I imagine we should run this twice, once for each example in the table. So we run Given something is step twice in total.

Based on my reading of how we process it today we only run it once. Does this line only go through the steps in the outline once? Shouldn't we be looping over the examples, not the steps? Here is the line: https://github.com/sittercity/gocumber/blob/master/gocumber.go#L156

I wrote a test like this:

func TestDocstrings_OutlineVariables(t *testing.T) {
        steps := make(Definitions)
        tt := new(testing.T)

        var called bool
        steps.Given("something is:", func(_ []string, step StepNode) {
                called = true
                assert.Equal(t, "minimally functional\n\n", step.PyString().String())
        })

        steps.Run(t, "test/valid_with_pystring_outline.feature")

        assert.True(t, called)
        assert.False(t, tt.Failed())
}

With the gherkin above. I put in a print statement like so:

        for _, original := range outline.Steps() {
                fmt.Printf("first outline: %v\n", original.Text())
                step := nodes.NewMutableStepNode(original.StepType(), replace(original.Text()))

                if original.Table() != nil {
                        table := nodes.NewMutableTableNode()

                        for _, row := range original.Table().Rows() {
                                replaced := make([]string, len(row))

                                for i, cell := range row {
                                        replaced[i] = replace(cell)
                                }

                                table.AddRow(replaced)
                        }

                        step.SetTable(table)
                } else if original.PyString() != nil {
                        pyString := nodes.NewMutablePyStringNode()
                        pyString.AddLine(replace(original.PyString().String()))

                        step.SetPyString(pyString)
                }

                callback(step)
        }

This is my output:

% make test
godep go test -cover .
first outline: something is:
--- FAIL: TestDocstrings_OutlineVariablesMultipleExamples (0.00s)
        gocumber.go:168: Scenario: Something
        Location:       gocumber_test.go:228
        Error:          Not equal: "minimally functional barely\n\n" (expected)
                                != "incredibly functional overwhelmingly\n\n" (actual)

FAIL
coverage: 100.0% of statements
FAIL    github.com/sittercity/gocumber  0.019s
godep: go exit status 1
make: *** [unit-test] Error 1

It seems to me that we should loop over the examples so we have two steps for this scenario outline.

Replace outline variables in docstrings

Feature: Scenario Outline with DocString

Scenario Outline: Something
  Given something is:
    """
    <how> functional
    """

Examples: 
  | how       |
  | minimally |

step.PyString().String() == "minimally functional\n"

heads up: gherkin3

Hi @cbandy, @ptrimble, @zombor,

awesome! …I'm very happy you've put my https://github.com/muhqu/go-gherkin to great use. ✨🎉

I'm not sure you're already aware of it, but cucumber is currently in the process of reimplementing it's gherkin parser and test runner. I've contributed a new version of the gherkin parser for golang, which is now compatible with all the grammar and language dialects. The main work gets done in a shared repository for all gherkin parser implementations (ruby, js, java, csharp, golang...)

• https://github.com/cucumber/gherkin3

But there is also a go-get-able subtree split repository:

• https://github.com/cucumber/gherkin-go

Maybe you folks are interested in contributing to a full-fledged go cucumber version. e.g. a tool that let users just type go cucumber to automatically find step definitions and run feature files...

/cc @aslakhellesoy, @nightlyone

Confusing error from undefined step with percent sign

An undefined step containing % prints poorly. For example,

When I get "/something/%{UUID}"

Causes the following output:

        gocumber.go:95: Undefined step:
                When I get "/something/%!{(MISSING)UUID}"

t.Errorf() should be t.Error().

Treat a Scenario as a unit

We currently run an entire feature file as one Go test. It probably makes more sense to run (i.e. pass/fail) individual scenarios.

Pending step definitions

It would be nice to get passed the "missing step" errors without much typing.

Maybe a nil function would suffice:

steps.Given("I have something", nil)

maybe you should have a look at

https://github.com/DATA-DOG/godog

Process 'Background' in Gherkin

We need to process Gherkin Backgrounds: http://docs.behat.org/en/latest/guides/1.gherkin.html#backgrounds

Should we rename repo to indicate v1?

What do we think about renaming this repo now to put -v1 in the name? This way when we make breaking changes we can clone to a new repo with a new name, thereby allowing people to upgrade gracefully.

I've seen this in a few places but I can't find them now. Thoughts?