At the top of a Gherkin feature file is the feature’s name or title. I recommend naming the feature with a concatenation of the full folder hierarchy and feature file name. I also recommend suffixing the feature name with the type of software component (such as User Interface, Service Layer, etcetera) so that feature files for the same related functionality are clearly discernible by the type of software component that implements them.
The template I find most useful for the name of a feature at the top of a feature file is:
Here is an example feature name, for a User Interface component:
And here is the same example feature, this time for the corresponding component in the service layer:
Different Feature Files, Same Behaviours
It is often the case that some of the exact same behaviour descriptions and Gherkin can be reused in the different feature files of each software component involved in the same logical grouping of functionality. For example, the feature files for both the User Interface and the back-end service layer involved in the same logical grouping of functionality could have the same behaviour descriptions and Gherkin. The back-end service may have additional behaviours for extra business logic that it alone must perform, but as a starting point, the initial set of behaviours could be the same.
As stated earlier, behaviours must always be considered and understood from within the context of and from the perspective of their software component / feature file. Even though the wording of the behaviour may be the same, the actual meaning and implementation will differ, based upon that context. This is why it is beneficial to suffix the feature name with the type of software component, as it is an important contextual differentiator.