How to manage and maintain feature files

[Robert Sabourin]

I have an interest in learning how different organisations manage and maintain feature files.

Do you know of any published examples or case studies?

cheers

take care

Rob Sabourin

[John Dee]

I doubt there are many. I personally think that feature files aren't being used correctly. I've almost never actually seen a non developer who can read them. The original idea being that it's a shared agile/ living doc between the devs and the biz stakeholders. My experience is that they get made, and eventually there is a non developer person higher up the food chain that simply ignores them because they are too complex for his non-developer brain. That person then brings the developer into a meeting to read the feature file, which he does by just reading it out loud with normal cadence and punctuation. In other words, the "scenario" format mystifies people who aren't programmers.

I break Gherkin down into a simple one line "should" sentence. Technically, the "should" sentence is just one line of a Gherkin scenario. ONE line each. 3 is too many for non developers. I consider Gherkin a developer doc only. Just get the biz person to say "it should.... " "it should ...", then the developer makes a full fledged Gherkin scenario out of the one line should sentence.

Here is a small tutorial on that subject:

https://generalchicken.guru/the-feature/

Good question though! I forwarded it to Quora:

https://www.quora.com/unanswered/What-is-an-example-of-an-organization-that-uses-Gherkin-feature-files-for-software-development

John Dee

Chief Idea Architect

https://wpdev.tv

[Daniel Terhorst-North]

I think it’s useful to look at where the idea of “feature files” came from. BDD is first and foremost about delivering customer value through collaboration. Closing the loop between demand, implementation, validation, and customer impact builds trust, and highlights where in the process things can be improved.

 

The biggest gap we saw at the time (early 2000s) was the gulf between what people (said they) wanted, and what developers (said they) built. Martin Fowler and I described this as The Yawning Crevasse of Doom. The problem is with the “(said they)” part. Written requirements are notoriously tricksy. They are incomplete by definition – I write them using my mental models, norms, and assumptions, you read them using your mental models, norms, and assumptions. This is known as the naïve realism bias: I think that you think like I think. Written specification is ambiguous by necessity – it cannot contain all the answers because the process of solving the problem changes the problem. It is a complex adaptive system.

 

So BDD grew out of a desire to reduce this crevasse by leveraging ideas from TDD and Domain-Driven Design. If developers write examples to guide the development, and if these examples can be self-documenting – literally writing out what they are verifying as they run – then they can become a powerful communication tool. There was an early tool called AgileDox that did this. It translated JUnit test names “testThisDoesSomething” into text “this does something” while the tests were running! This is what started me on test names as documentation.

 

Once you have this, the next level is to have your examples print out each line of what they are doing, not just the title. From here it is a short hop to a given-when-then structure and narrative scenarios.

 

All this is to say, I have always viewed plain text rendering of scenarios and tests as an output of the build rather than an input. It takes a lot of hidden work and complexity to map plain text feature files to the sequence of steps that execute, and there has to be a significant payoff before I will even use something like Cucumber. The vast majority of BDD I’ve ever done – at the story and scenario level – has used Plain Old JUnit or pytest. As long as a non-technical stakeholder can see the results of the run in plain text, we have eliminated that gap.

 

Liz (and others I’m sure) has said before that the real communication win is in the scenario titles. “The one where …”. This encourages conversations around scope and edge cases which is where much of the ambiguity hides. Making the scenarios both automated and self-documenting goes a long way to closing that feedback loop I mentioned at the beginning, and the Three Amigos conversations (h/t George D.) are the perfect forum for surfacing those scenarios.

 

So yes, I agree people are mostly using feature files incorrectly, because they are using them at all!

 

Kind regards,

--

Daniel Terhorst-North

+44 (0)7580 099876
https://dannorth.net

@tastapod
Dan North & Associates Ltd, 14 Lady Hay, Worcester Park, KT4 7LT, UK
Registered in England and Wales, no. 6716833. VAT no. GB 137 7822 88

--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendeve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/behaviordrivendevelopment/9fcc6708-d493-4935-8114-bbdb79094cf2n%40googlegroups.com.

[Liz Keogh]

Yep. I tend to use a custom DSL written in JUnit / NUnit these days. The least technical person I've found reading scenarios has been the Product Owner, and they can read DSLs just fine; all other non-tech stakeholders just want evidence that you're being sensible. The DSL also gives the reusability of steps that helps keep the system-level scenarios maintainable (I just use G/W/T in comments at a unit level since steps aren't generally reused due to single responsibility of classes).

I wrote a blog post on it for y'all!

Cheers,

Liz.

To view this discussion on the web visit https://groups.google.com/d/msgid/behaviordrivendevelopment/011401d6c252%24c88cb620%2459a62260%24%40dannorth.net.

--

Liz Keogh
l...@lunivore.com
http://lizkeogh.com
http://lunivore.com

[Andrew Premdas]

So I've been using feature files 'correctly' for many years now, but rarely have I been able to get stakeholders that interested in them even though all my feature files are simple succinct and clear. I use Cucumber all the time because it is a way to get natural language into the code base, it gives a living high level map of my application, and it really helps me write simpler cleaner code, as by the time I've written and started implementing a decent cuke I have

- what I am developing

- why I am developing it

- most (if not all) of the naming sorted

- most of the api of my code designed and specified

- the structure of my visual elements

- the organisation of my CSS and what to expect (when writing web apps)

- a mechanism for getting into my code (via a debugger) and for getting to the precise parts of my code that need addition and change

For me the main benefit of Cuking isn't about collaborating to decide what to develop. As others have pointed out you have a huge number of other choices to do this, many of which are more appropriate and effective for many organisations and groups of people. The main benefit is that a good cuke drives good code. Its that fundamental BDD idea that a clear and succinct understanding of behaviour is a terrific driver of development. And once you have a good cuke implemented you have a great regression tool, living documentation of what you were doing and why it was considered important, and something that provides a foundation for future work and a terrific access point when something goes wrong.

My personal process is to collaborate with my stakeholders to decide what to build and why, and then use cukes to refine and document my understanding of the results of that collaboration and then connect to and drive my application code. Then I live with these cukes as an integral part of my codebase, and that's where I really see their benefit, as each piece of clearly defined behaviour is also accompanied by a toolset that allows me to build on that now existing behaviour to develop new behaviour.

All best

Andrew

To view this discussion on the web visit https://groups.google.com/d/msgid/behaviordrivendevelopment/CAFb2DEH3VsiA3XM7b_66TgQZPS4tK1Zg7ai4QXx8aqyUcx-EyQ%40mail.gmail.com.

--

------------------------

Andrew Premdas

blog.andrew.premdas.org

[George Dinwiddie]

Using "should" sentences is one way of specifying a system. That's the
way large requirements document have long been written (though "shall"
is preferred for requirements that must be met). Despite the intent of
IEEE 830 that requirements documents not specify design, once you take
the point of view of describing the system in terms of it's own
behavior, the language to do so already makes design assumptions.

I like using Gherkin, even for solo work, because it helps me get out of
the mode of thinking about implementation and into the mode of thinking
about examples of interaction from the user's point of view. I write
these very differently than when specifying system behavior in junit or
rspec or other technically-oriented manner.

What I notice in clients, is that many people, instead of approaching
the description from the user/business point of view, they warp gherkin
into the technically-oriented approach that's familiar to them. Perhaps
it's easier for me to make this shift, having taken a detour out of
technology and majored in English in college. Believe me, expressing
things clearly in natural language is not easy, but I think it's worth
the effort.

I further notice that the people representing the business' interests
when talking to development teams are rarely business people. They are
product owners or business analysts, roles created by the IT industry
rather than by the business. These people try to have one foot on the
development side and one foot on the business side, to varying degrees
of success. Yes, they often will accept technically-oriented
descriptions, and may even prefer them. I've seen this come about either
from their having a technical background themselves, or from long
experience trying to communicate with development teams.

In fact, I've seen them become accustomed to this that their skills at
communicating with the business have started to atrophy, moving the gap
between business and technical to a different interface rather than
solving the problem.

I note that gherkin is NOT a software specification language. It is,
instead, an example description language. Well-crafted examples can go a
long way to verifying common understanding and highlighting ambiguity or
varied interpretations of the same words. Using this to verify the
communication between the business and the development teams is a
fabulous thing, if only people will do so.

The automated tests are a bonus for the development staff, and a
cost-saving measure for the business. They are not the central point of
feature files.

Communication between people is hard, and there will never be a perfect
general solution. The Given When Then template is, admittedly, too
restrictive for some people to think in natively. Perhaps there are
other templates that could be used.

In my experience, not constraining the business people but offering them
a restatement in GWT form (sometimes pronouncing "given" as "if")
usually works pretty well. Well, except when they'be become so
accustomed to asking for what they want in technical terms instead of in
business terms that they no longer can do otherwise.

If anyone wants to explore specific examples, I'd be glad to do so with
them.

- George

> --
> You received this message because you are subscribed to the Google
> Groups "Behaviour Driven Development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to behaviordrivendeve...@googlegroups.com

> <mailto:behaviordrivendeve...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/behaviordrivendevelopment/9fcc6708-d493-4935-8114-bbdb79094cf2n%40googlegroups.com

> <https://groups.google.com/d/msgid/behaviordrivendevelopment/9fcc6708-d493-4935-8114-bbdb79094cf2n%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach https://pragprog.com/titles/gdestimate/
----------------------------------------------------------------------

[Liz Keogh]

Hi Andrew,

I think if you're using a dynamic language (so refactoring is tricky anyway) then there's little downside to using an English-language tool. For statically typed languages, though, having maintainable feature files (i.e. in code) can trump the benefits of plain text. All the other benefits of BDD still apply; any related text just goes in comments or in other areas of the code like method names.

(It isn't like I haven't tried the plain text tools either...)

As an aside, I really enjoyed doing README-driven development. It's a great way to get the high-level capabilities sketched out in a useful place.

Cheers,

Liz.

To view this discussion on the web visit https://groups.google.com/d/msgid/behaviordrivendevelopment/CAMxjd8Nt%2BM9GY3VtjFDim2ug%2BvGTXZz_QNHC-hyKfvdOzn%3DTQw%40mail.gmail.com.

[George Dinwiddie]

Liz,

My approach has been to have a very thin English-language layer, which
concentrates on intent, and support that with test code very quickly.
The intent doesn't need refactoring. The test code is refactored in the
process of refactoring production code.

I wrote Evolutionary Anatomy (https://leanpub.com/EvolutionaryAnatomy)
to show how the details get pushed down below the step definition level
as the system and tests grow.

- George

> <https://lizkeogh.com/2019/08/27/scenarios-using-custom-dsls/>

>
> Cheers,
> Liz.
>
> On Tue, Nov 24, 2020 at 11:16 AM Daniel Terhorst-North
> <dan...@dannorth.net <mailto:dan...@dannorth.net>> wrote:
>
> I think it’s useful to look at where the idea of “feature
> files” came from. BDD is first and foremost about delivering
> customer value through collaboration. Closing the loop
> between demand, implementation, validation, and customer
> impact builds trust, and highlights where in the process

> things can be improved.____
>
> __ __

>
> The biggest gap we saw at the time (early 2000s) was the
> gulf between what people (said they) wanted, and what
> developers (said they) built. Martin Fowler and I described
> this as The Yawning Crevasse of Doom

> <https://www.infoq.com/presentations/Fowler-North-Crevasse-of-Doom/>.

> The problem is with the “(said they)” part. Written
> requirements are notoriously tricksy. They are incomplete by
> definition – I write them using my mental models, norms, and
> assumptions, you read them using your mental models, norms,
> and assumptions. This is known as the naïve realism

> <https://en.wikipedia.org/wiki/Na%C3%AFve_realism_(psychology)>bias:

> I think that you think like I think. Written specification
> is ambiguous by necessity – it cannot contain all the
> answers because the process of solving the problem changes

> the problem. It is a complex adaptive system.____
>
> __ __

>
> So BDD grew out of a desire to reduce this crevasse by
> leveraging ideas from TDD and Domain-Driven Design. If
> developers write examples to guide the development, and if
> these examples can be self-documenting – literally writing
> out what they are verifying as they run – then they can
> become a powerful communication tool. There was an early
> tool called AgileDox that did this. It translated JUnit test
> names “testThisDoesSomething” into text “this does

> something” /while the tests were running!/ This is what
> started me on test names as documentation.____
>
> __ __

>
> Once you have this, the next level is to have your examples

> print out /each line/ of what they are doing, not just the

> title. From here it is a short hop to a given-when-then

> structure and narrative scenarios.____
>
> __ __

>
> All this is to say, I have always viewed plain text

> rendering of scenarios and tests as /an output of the build/

> rather than an input. It takes a lot of hidden work and
> complexity to map plain text feature files to the sequence
> of steps that execute, and there has to be a significant
> payoff before I will even use something like Cucumber. The
> vast majority of BDD I’ve ever done – at the story and
> scenario level – has used Plain Old JUnit or pytest. As long
> as a non-technical stakeholder can see the results of the

> run in plain text, we have eliminated that gap.____
>
> __ __

>
> Liz (and others I’m sure) has said before that the real

> communication win is in the scenario /titles/. “The one

> where …”. This encourages conversations around scope and
> edge cases which is where much of the ambiguity hides.
> Making the scenarios both automated and self-documenting
> goes a long way to closing that feedback loop I mentioned at
> the beginning, and the Three Amigos conversations (h/t
> George D.) are the perfect forum for surfacing those

> scenarios.______
>
> __ __

>
> So yes, I agree people are mostly using feature files

> incorrectly, because they are using them at all!____
>
> __ __
>
> Kind regards,____
>
> --____
>
> *Daniel Terhorst-North*____
>
> +44 (0)7580 099876 <tel:+447580099876>
> https://dannorth.net
> <https://ind01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3Db7bd1023-eb9e05fa-b7bc9adc-ac1f6b00f158-3e11ce03895c6d74%26q%3D1%26e%3D9a83a0ce-7fc2-42aa-ad6e-2bf6e5d6db3c%26u%3Dhttps%253A%252F%252Fdannorth.net%252F&data=02%7C01%7CGaurav.Luhadiya%40ril.com%7Ce4ea1911aca84fa497f708d8694cf2c1%7Cfe1d95a94ce141a58eab6dd43aa26d9f%7C0%7C0%7C637375126541739391&sdata=CTlK7xzL2TGohmW2sM5jlko14KzR1U9iSF9VUahbrx4%3D&reserved=0>____
>
> @tastapod
> <https://ind01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Ftastapod&data=02%7C01%7CGaurav.Luhadiya%40ril.com%7Ce4ea1911aca84fa497f708d8694cf2c1%7Cfe1d95a94ce141a58eab6dd43aa26d9f%7C0%7C1%7C637375126541749382&sdata=FK0q4t8GSOtSBMs0XwmAuxfVoN7U2pbRFdXM7htvYQ0%3D&reserved=0>
> /Dan North & Associates Ltd, 14 Lady Hay, Worcester Park,

> KT4 7LT, UK
> Registered in England and Wales, no. 6716833. VAT no. GB 137

> 7822 88/____
>
> __ __
>
> *From:*behaviordriv...@googlegroups.com
> <mailto:behaviordriv...@googlegroups.com>
> <behaviordriv...@googlegroups.com
> <mailto:behaviordriv...@googlegroups.com>> *On
> Behalf Of *John Dee
> *Sent:* 24 November 2020 04:41
> *To:* Behaviour Driven Development
> <behaviordriv...@googlegroups.com
> <mailto:behaviordriv...@googlegroups.com>>
> *Subject:* [BehaviourDrivenDevelopment] Re: How to manage
> and maintain feature files____
>
> __ __

>
> I doubt there are many. I personally think that feature
> files aren't being used correctly. I've almost never
> actually seen a non developer who can read them. The
> original idea being that it's a shared agile/ living doc
> between the devs and the biz stakeholders. My experience is
> that they get made, and eventually there is a non developer
> person higher up the food chain that simply ignores them
> because they are too complex for his non-developer brain.
> That person then brings the developer into a meeting to read
> the feature file, which he does by just reading it out loud
> with normal cadence and punctuation. In other words, the

> "scenario" format mystifies people who aren't programmers.____
>
> __ __

>
> I break Gherkin down into a simple one line "should"
> sentence. Technically, the "should" sentence is just one
> line of a Gherkin scenario. ONE line each. 3 is too many for
> non developers. I consider Gherkin a developer doc only.
> Just get the biz person to say "it should.... " "it should
> ...", then the developer makes a full fledged Gherkin

> scenario out of the one line should sentence.____
>
> __ __
>
> Here is a small tutorial on that subject:____
>
> https://generalchicken.guru/the-feature/
> <https://generalchicken.guru/the-feature/>____
>
> __ __
>
> Good question though! I forwarded it to Quora:____
>
> https://www.quora.com/unanswered/What-is-an-example-of-an-organization-that-uses-Gherkin-feature-files-for-software-development
> <https://www.quora.com/unanswered/What-is-an-example-of-an-organization-that-uses-Gherkin-feature-files-for-software-development>____
>
> __ __
>
> John Dee____
>
> Chief Idea Architect____
>
> https://wpdev.tv <https://wpdev.tv>____
>
> __ __
>
> __ __
>
> __ __

>
> On Monday, June 10, 2019 at 9:31:44 AM UTC-7

> rob...@gmail.com <mailto:rob...@gmail.com> wrote:____
>
> __ __

>
> I have an interest in learning how different

> organisations manage and maintain feature files.____
>
> __ __
>
> Do you know of any published examples or case studies?____
>
> __ __
>
> cheers____
>
> __ __
>
> take care____
>
> __ __
>
> Rob Sabourin____

>
> --
> You received this message because you are subscribed to the
> Google Groups "Behaviour Driven Development" group.
> To unsubscribe from this group and stop receiving emails
> from it, send an email to
> behaviordrivendeve...@googlegroups.com

> <mailto:behaviordrivendeve...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/behaviordrivendevelopment/9fcc6708-d493-4935-8114-bbdb79094cf2n%40googlegroups.com

> <https://groups.google.com/d/msgid/behaviordrivendevelopment/9fcc6708-d493-4935-8114-bbdb79094cf2n%40googlegroups.com?utm_medium=email&utm_source=footer>.____

>
> --
> You received this message because you are subscribed to the
> Google Groups "Behaviour Driven Development" group.
> To unsubscribe from this group and stop receiving emails
> from it, send an email to
> behaviordrivendeve...@googlegroups.com

> <mailto:behaviordrivendeve...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/behaviordrivendevelopment/011401d6c252%24c88cb620%2459a62260%24%40dannorth.net
> <https://groups.google.com/d/msgid/behaviordrivendevelopment/011401d6c252%24c88cb620%2459a62260%24%40dannorth.net?utm_medium=email&utm_source=footer>.
>
>
>
> --
> Liz Keogh
> l...@lunivore.com <mailto:l...@lunivore.com>
> http://lizkeogh.com <http://lizkeogh.com>
> http://lunivore.com <http://lunivore.com>

>
> --
> You received this message because you are subscribed to the
> Google Groups "Behaviour Driven Development" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to
> behaviordrivendeve...@googlegroups.com

> <mailto:behaviordrivendeve...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/behaviordrivendevelopment/CAFb2DEH3VsiA3XM7b_66TgQZPS4tK1Zg7ai4QXx8aqyUcx-EyQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/behaviordrivendevelopment/CAFb2DEH3VsiA3XM7b_66TgQZPS4tK1Zg7ai4QXx8aqyUcx-EyQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
>
>
> --
> ------------------------
> Andrew Premdas
> blog.andrew.premdas.org <http://blog.andrew.premdas.org>

>
> --
> You received this message because you are subscribed to the Google
> Groups "Behaviour Driven Development" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to
> behaviordrivendeve...@googlegroups.com

> <mailto:behaviordrivendeve...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/behaviordrivendevelopment/CAMxjd8Nt%2BM9GY3VtjFDim2ug%2BvGTXZz_QNHC-hyKfvdOzn%3DTQw%40mail.gmail.com
> <https://groups.google.com/d/msgid/behaviordrivendevelopment/CAMxjd8Nt%2BM9GY3VtjFDim2ug%2BvGTXZz_QNHC-hyKfvdOzn%3DTQw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
>
>
> --
> Liz Keogh
> l...@lunivore.com <mailto:l...@lunivore.com>
> http://lizkeogh.com <http://lizkeogh.com>
> http://lunivore.com <http://lunivore.com>

>
> --
> You received this message because you are subscribed to the Google
> Groups "Behaviour Driven Development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to behaviordrivendeve...@googlegroups.com

> <mailto:behaviordrivendeve...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/behaviordrivendevelopment/CAFb2DEHG8Tt%2Biou8L49%2BHgLaCV%3D2XZ%2BcD_7b3zfodvv%3Doi-Eyw%40mail.gmail.com
> <https://groups.google.com/d/msgid/behaviordrivendevelopment/CAFb2DEHG8Tt%2Biou8L49%2BHgLaCV%3D2XZ%2BcD_7b3zfodvv%3Doi-Eyw%40mail.gmail.com?utm_medium=email&utm_source=footer>.