Add support for Gherkin / Gherkin Spec

[LeoColman]

Although we have have BehaviorSpec, a big necessity that I've been observing in some projects that test Java/Kotlin code is using the CucumberRunner.

With tests written in Gherkin, a team can generate a powerful suite of tests that are read from a .feature file, in natural language, and then transform it into code.

However, the code written to be executed by CucumberRunner is quite Cucumbersome (see what I did there riaria), and it leads to easy to understand specification feature file, but often hard to understand executable code, and hard to setup too.

I propose we implement a Gherkin Spec, that would read from a configurable file and execute the scenario based on that .feature file.

If we believe this is a good feature, I'm glad to enhance this small feature request to a more robust suggestion.

[sksamuel]

Personally I think cucumber is total shit. The reason is when I was forced to use it about 5 years ago I had to create loads of text files, loads of annotations, and put together tests in a way that was 10x slower than just writing them in code properly.

The rationale - that "non techies" can read the tests. Well that's nonsense - BA's can't write cucumber tests anymore than they can write scalatest.

If you want to come up with another spec, that's elegant and read from a file, crack on, but I don't want to see anything as bloated and crap as cucumber.

[LeoColman]

I don't really like cucumber either, but some people think that it's the best approach to BDD.

Maybe instead of implementing a full gherkin spec, we could add keywords for the BehaviorSpec to make it closer to the Gherkin alternative?

For instance, Scenario, BackgroundScenario, Given -> And -> And -> When -> .... I agree that the .feature files are mainly for QAs to write the tests without knowing how to implement, but maybe if instead they could open a code file and do:

Feature("Foo bar feature") {
    Given("The Foo") {
        And ("The Bar") {
            When("The foo foos") {
                And("The bar bars") {
                    Then("The foo should bar") {
                    }
                    Then("The bar should foo") {
                    }
                }
            }
        }
    }
}

[sksamuel]

Are you just trying to turn KotlinTest into Spek :)

Personally I'm a no, I think it's a limited use syntax and we already have a lot of specs that there should be a good case for another.

But if you feel really strongly about it...

[LeoColman]

God, no.

I feel strong about it because Cucumber is used A LOT, and a lot of people are very familiar with it. My suggestion is to bring these people here to write good code instead of writing it in the clunky way cucumber does.

I really dislike cucumber, but the idea of writing a test without caring about the implementation is really good for quality assurance and black box testing. I want a way to support this kind of testing, and I have no idea other than cucumber/gherkin.

We may keep this on hold for now and focus on all the other enhancements that we have planned, but this kind of testing is very good, just poorly executed, IMO

[sksamuel]

What's wrong with someone creating a jira with acceptance criteria in it? In my experience too much process is overengineering.

But surely BA's et al, can work out a string spec? It's pretty simple.
But again as I've said open to ideas.

[LeoColman]

I think that with the additions from #562 BehaviorSpec got better, and there's no longer a real need for something stronger that the BDD implemented there.

Because of this, I'll be closing this issue