It depends on the target audience of the feature as written. It seems highly likely that the gherkin you’ve got there was not written with a stakeholder (i.e. somebody not-techie but has a vested interest in the business and the website). BDD is really about the conversation about requirements and expectations – and Gherkin is a tool which gives a standard/recognised way that everyone should be able to read that you can write the requirements and expectations; in a way that serves as automated tests for a developer and perhaps test scripts for a tester.
Trying to take my developer hat off now – I would say that a business stakeholder would rather read, and understand easily…
Scenario: Should be able to successfully register on website
Given I am new to the website
And I want to register for a user account
When I go to the registration form
And I complete all the required registration details correctly
Then I will be registered on the website
And I will be automatically logged in
You can still build the same test behind the scenes of this specification – but this specification has larger readership, it is a more easily understood requirement that anyone should understand. I’m not saying what you have got has no value – far from it. It will be a very valid test. But it is quite developer specific, and highly coupled to the UI implementation (if you refactor/redesign the UI, you now need to refactor your Requirements…).
I started off having plenty of gherkin specifications much like yours – and I still use them on occasion. Once your testing framework has built up a little gherkin is a really great way of kind of writing data-driven/configurable unit tests; and they still have great value to my development process. But I do try to separate the more “pure” specifications from my “developer” ones – but folder and tags/categories.
Edit: I guess in summary what I’m getting at is… what you have is a great “test”, but a fairly bad “requirement”. Stick with it though!