I found this to be the case when writing a Cucumber test for an Emacs package. You can see an example here: <a href="https:&#x2F;&#x2F;github.com&#x2F;omouse&#x2F;org-doing&#x2F;blob&#x2F;master&#x2F;features&#x2F;org-doing.feature" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;omouse&#x2F;org-doing&#x2F;blob&#x2F;master&#x2F;features&#x2F;org...</a><p>It was more helpful to write &quot;Given I have an non-existent file&quot; than to write &quot;(not (file-exists-p org-doing-file))&quot;. One can be read by others who don&#x27;t understand Emacs-Lisp and they&#x27;ll understand the concept, while the latter can only be read by Emacs-Lisp developers. With the Gherkin syntax I&#x27;m free to move my tests over to another text editor and implement code that&#x27;s specific to the text editor. For example, I could use my tests to implement the package for VIM or Atom (something I might do on a weekend).<p>The best part is that you have the spec under version control and locked down instead of spread across.<p>At work no one is really updating the functional spec of our project and it means we have information that&#x27;s falling through the cracks and is in separate emails or IMs. Executable version-controlled specs have to be maintained but at least they&#x27;re in one spot.