In an earlier post, I promoted the idea that Gherkin scenarios should find a sweet spot between the interests of business stakeholders and test implementers. In this post, I want you to forget all that and ignore the test implementer and focus only on the business stakeholder... at least when writing scenario names.

Scenario names have no implementation code associated with them. So, they provide an unique opportunity to be completely unencumbered by test implementation considerations. So, flex your language skills! Find the most meaningful way to express the requirement this scenario represents.

On one project, the requirements writers were spending a great deal of time studying legacy code to understand the requirements for a system rewrite. After hours immersed in the code, we found them writing scenario names similar to this:

Scenario: Prevent assigning someone to a room that is already assigned to someone else on the new assignment's start date, where both the new and existing assignment start on the same day and the new assignment has no end date

Whew! It showed meticulous understanding of the legacy logic. But, what is it