Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Gherkin Scenarios for User Input Validation

Tags:

bdd

When writing a BDD scenario that is validating information on an input form, how would you list rules.

Options are:

1) A single scenario each rule 2) Scenario outline with examples for each field and rule

How do we say something is invalid that is not in a certain character set, e.g:

Given I enter a value that breaks the rule.. When I do something Then I should see an error .....

Would you generate random values that break the rule?

Thanks, James

like image 831
James Avatar asked Apr 20 '10 10:04

James


People also ask

What is an example of input validation?

For example, validating that an input value is a credit card number may involve validating that the input value contains only numbers, is between 13 and 16 digits long, and passes the business logic check of correctly passing the Luhn formula (the formula for calculating the validity of a number based on the last “ ...

How do you write a good Gherkin scenario?

Gherkin's Golden Rule. Gherkin's Golden Rule is simple: Treat other readers as you would want to be treated. More specifically, write feature files so that everyone can intuitively understand them. Good Gherkin should improve team collaboration by clarifying behaviors you want to develop.

Are Gherkin scenarios with multiple when then pairs okay?

The Cardinal Rule is a way to break out of the procedure-driven mindset, and banning multiple When-Then pairs per Gherkin scenario is an effective rule for enforcing it.

What is the two main purpose of using gherkin?

Gherkin is a Business Readable, Domain Specific Language created especially for behavior descriptions. It gives you the ability to remove logic details from behavior tests. Gherkin serves two purposes: serving as your project's documentation and automated tests.


1 Answers

With validation, I've done one of these:

  • validated each kind of thing that might go wrong, or
  • captured the validation behaviour with unit tests, then just described how I, the user, will see the validation message
  • captured the common things that users do wrong and described how the system will help me to get it right.

I find the second and third ones easier to maintain, especially using a BDD tool, given that English is hard to refactor and validation rules often change. If there's no higher-level business capability which is provided, as in the third situation, then I'd just do the second one.

BDD isn't really about testing. It's about coming to a shared understanding and capturing that in a way which helps that understanding play into the code. You get tests as a wonderful by-product.

Hope that helps.

like image 80
Lunivore Avatar answered Sep 22 '22 19:09

Lunivore