Gherkin Support

[sashokbg]

Do you plan to add some sort of gherkin / cucumber support to the Bruno tool ?

It would be nice if we could use gherkin files as described in the cucumber doc https://cucumber.io/docs/gherkin/
to create collections.

Let me know what you think.
Best Regards

[rabestro]

It would be nice if we could use gherkin files as described in the cucumber doc https://cucumber.io/docs/gherkin/ to create collections.

The Karate Framework uses Gherkin syntax for API tests.
Do you think this format is better then Bruno format for API tests?

[sashokbg]

The problem I see with karate is that it focuses on the technical part. "Given POST call" "When Header is Authorization" etc.
I would rather have "Given a user" -> that is mapped to a .bru file that performs the post.
"When they connect" -> mapped to another .bru etc.

This way we can maybe also reuse steps.

[notfounnd]

BDD Is Not About Testing, from Dan North (Creator of BDD)
https://www.youtube.com/watch?v=6nSwRSbc27g

BDD is not test automation, from Aslak Hellesøy (Creator of Cucumber)
https://cucumber.io/blog/bdd/bdd-is-not-test-automation/

[Raiondesu]

While this is all well and good context for the topic, the fact that "BDD is not test automation" doesn't automatically imply that Gherkin support for Bruno is somehow against BDD, so your thumbs-down to the OP is not justified at all.

Quoting the article you linked:

[TDD and BDD] produce tests as a by-product, but they are not testing activities.

It doesn't matter what those tests are, only that they serve as concrete and agreed-upon interpretations of requirements.
The point of the article is not that BDD somehow forbids testing, it's that creating tests is simply not the focus nor reason for practicing BDD. This doesn't mean that the produced tests cannot function as auto-tests. In fact, it's the opposite! Automation of tests-as-documentation is the whole central idea of the Automation stage.

Having support for Gherkin in Bruno would simply allow Bruno tests to be another one of the "by-products of BDD", exactly as intended by Cucumber's creators.
Denying this point would mean that any and all technical implementations of Gherkin tests are "wrong" by transitivity, which is just absurd, because having diverse options for underlying tests' implementations is the entire point of Gherkin as a language in the first place.

There is no categorical difference between Bruno tests and API tests in, for example, JS, in regards to what these tests do. There's nothing stopping people from writing API tests in Cucumber with something like PactumJS. Actually, it's encouraged!
Writing API tests in Cucumber with Bruno would just be a simpler and more streamlined option for those.

[notfounnd]

Denying this point would mean that any and all technical implementations of Gherkin tests are "wrong"

It are wrong when it comes to implementations aimed at test automation. And it is because of this type of thinking that the complexity in creating and maintaining automation projects has grown excessively.

People look at Gherkin, especially managers, and start demanding that automations be built with it. They replace the definition of a test method (one line) with a layer and a lot of text that no one but the tester who creates all this will read. Unnecessary complexity.

So, yes, any implementation of tests in Gherkin is wrong. They should be seen as development specifications, not tests.

The indicator of this is that using BDD or TDD to guide development does not eliminate the need for complementary validations to generate reliable feedback for development.