Misusing Gherkin

Gherkin is not so much of a programming language, but a means to clearly identify the purpose of a test. With that said, I recently attended a presentation by a QA representative from RedMart at a tech conference. There, I observed how Gherkin can be misused to encompass everything and anything about the test. Like so:

Given that user is a platinum member
And user is using a pre-paid method
And user is from Singapore

When the user clicks on login
And enters his Google account username
And enters his Google account password
And enter his one-time-password

Then he should see a price filter
And he should be able to click on the price filter
And he should be able to enter a price in the hundreds
And he should be able to select a product
And he should be able to add the product to cart

The above is a classic case of TMI - Too Much Info. There are one too many And statements.

To recap - Given should be used to describe the initial system state, When describes the state change and Then should be the test expectation. These statements should be as much as possbile kept to one-liners. With that said, I also took issue with the presenter using the Gherkin steps to locate an element in the webpage, which added more lines to the already long feature file.

A better way to Gherkin would be as such:

Given a platinum pre-paid member from Singapore
When the member logs in with his Google account
Then he should be able to filter the products by price

So, what happened to the explicit And statements? The action for the And statements should be encapsulated in function of the Given/When/Then statement being referenced. You can still use And statements, but keep them to a minimum for readability. I recommend using a maximum of 2 And statements per Given/When/Then.