5 ms·
Ask HN: Better way to write specs?
Is there a standard way of writing BDD specs in a rule-based format? To me, the traditional Gherkin-style format is too verbose and depends on defining edge-cases in lengthy scenarios.
I'm looking for something that more defines the business logic in English and covers the edge cases in the test code.
Like:
Feature: Serve coffee
Rule: If there is no coffee left, refund the money
Otherwise:
Rule: Coffee should not be served until paid for and until the button has been pressed
Rule: If the customer is on the VIP list, don't charge any money
Instead of:
Feature: Serve coffee
Coffee should not be served until paid for
Coffee should not be served until the button has been pressed
If there is no coffee left then money should be refunded
Scenario: Buy last coffee
Given there are 1 coffees left in the machine
And I have deposited 1$
When I press the coffee button
Then I should be served a coffee
Scenario: VIP buys coffee
Given there are 1 coffees left in the machine
And I have deposited 1$
And I am on the VIP guest list
When I press the coffee button
Then I should be served a coffee
Then my money should be returned
.. scenario for VIP trying to buy coffee, but no coffee left
.. scenario for regular user trying to buy coffee, but no coffee left, etc.
(example from: https://github.com/cucumber/cucumber/wiki/Feature-Introduction)
- beat 11y agoI just use plain English for that, always a one-sentence summary. Details are for traditional BDD language, which has the advantage of being machine-readable to generate test stubs. The purpose of the one sentence summary is not to be complete, but to keep large feature lists readable at a glance.
- everdev 11y agoRight, but is there a common DSL for business logic that's not Gherkin? Something that would be easy enough for stakeholders to read, but also specific enough for developers to write tests against and enter as a ToDo on a Kanban board?
- beat 11y agoNot that I know of. Gherkin is the simplest language I know of with any sort of rigor. Less than that, and you start falling on non-rigorous language that will have gaps of meaning, intent, and completeness. What you came up with was pretty good. Good luck enforcing it with nontechnical stakeholders, though.