How do you do field validation in a Cucumber scenario? I got this question recently, and wanted to share a few techniques I've personally found helpful. Here's one option: This is a classic data-driven approach. It is pretty readable....
How do you do field validation in a Cucumber scenario?
I got this question recently, and wanted to share a few techniques I've personally found helpful.
Here's one option:
This is a classic data-driven approach. It is pretty readable.
But the test will reload the page for each variation, which might not be optimal.
What else could we do?
Here we use soft asserts to perform multiple checks on the same page. Not a conventional use of Gherkin, but it is perfectly readable, and would run quickly as well.
But what if we need to check all the fields on a page? Well, how about this?
This is a bit more sophisticated - it dynamically fills each field with an empty value, and checks the corresponding error message using soft assertions. It is readable and efficient, at the cost of more complexity under the hood in the glue code.
All these options could work.
But here's the thing: field validation is often too granular to be of much interest for a business user - it's often considered to be something that should "just work".
Business folk are (or should be!) more interested in what happens AFTER the values are entered, not in the nitty-gritty details of field validation.
So write scenarios like this if it helps build confidence in your software - or simply write UI-level unit tests to do the same job. But make sure you have the conversations with the business folk about what happens next, and put THAT in your scenarios as well.
The post How do you do field validation in Gherkin? appeared first on John Ferguson Smart.