[Gherkin] Feature Syntax Edge Cases

[Mike Sassak]

Hi Everyone,

With the work on integrating Gherkin with Cucumber and implementing
the C-version of the parser, we've stumbled across a few edge cases in
the Gherkin syntax. Neither appear to be common, so it's probably not
a big deal, but it'd be great to get a reading on how many people (if
any) are actually depending on these parts of the current behavior.
The two cases that have come up are:

1) "Preambles" before the Feature keyword. E.g. http://gist.github.com/216194
2) The Treetop parser doesn't actually require the Feature keyword
before any scenarios.

#1 can be worked around by commenting out the preamble or, even
better, moving it below the Feature as part of the Feature description
/ narrative.

#2 is a bit trickier. How many people depend on bare scenarios? If you
don't do this currently, but think it's a great idea anyway, speak up.
On the same note, I wouldn't recommend that anyone begin using this
style, at least not yet, because support for it might be dropped in
the relatively near future. A lot depends on how in use it is already.

So let's hear it. Do you use bare scenarios? Would you *like* to use
bare scenarios?

Thanks,
Mike

[Richard Lawrence]

Bare scenarios are used in Cucumber's own tests (when simple feature
files are generated), and I do the same in my Cuke4Nuke tests. On
other projects, I've always used a Feature at the top.

Richard

[Mike Sassak]

On Thu, Oct 22, 2009 at 6:02 PM, Richard Lawrence
<ric...@humanizingwork.com> wrote:
>
> Bare scenarios are used in Cucumber's own tests (when simple feature
> files are generated), and I do the same in my Cuke4Nuke tests. On
> other projects, I've always used a Feature at the top.
>

Discovering that bare scenarios were used within Cucumber itself was
what prompted me to send the email, actually. There are a few options
to continue testing with bare scenarios and Gherkin, (some of which
are even kind of elegant!), but if many people use bare scenarios in
production, it might make more sense to just change what Gherkin
recognizes as valid syntax. If not, then the workarounds should be
fine.

Thanks for the heads up! I'll make sure to let you know if you can't
depend on the bare scenarios any more.

[Matt Wynne]

On 22 Oct 2009, at 23:23, Mike Sassak wrote:

>
> On Thu, Oct 22, 2009 at 6:02 PM, Richard Lawrence
> <ric...@humanizingwork.com> wrote:
>>
>> Bare scenarios are used in Cucumber's own tests (when simple feature
>> files are generated), and I do the same in my Cuke4Nuke tests. On
>> other projects, I've always used a Feature at the top.
>>
>
> Discovering that bare scenarios were used within Cucumber itself was
> what prompted me to send the email, actually. There are a few options
> to continue testing with bare scenarios and Gherkin, (some of which
> are even kind of elegant!), but if many people use bare scenarios in
> production, it might make more sense to just change what Gherkin
> recognizes as valid syntax. If not, then the workarounds should be
> fine.

I'm going to be surprised if we find very many people who are
currently using features that don't begin with a "Feature: Feature
Name" line, but I'd suspect that's because the examples and tooling
(e.g. TextMate bundle) very much push you down that path. Few people
have probably even realised it is possible to miss out this line and
as Aslak said, it's only really an accident that it is. However, just
because not many people are using it doesn't necessarily mean we
should close out the option.

I've always thought of Features within Cucumber as just a fairly
arbitrary way to group Scenarios together. I often split a feature
file when it starts to contain too many Scenarios, or move a Scenario
around from one feature file to another. They're definitely a useful
way to help organise scenarios, but other mechanisms like tags are
also useful.

I personally think think of the Scenario as the heart of the model,
which might or might not be contained by a feature:

http://yuml.me/diagram/scruffy/class/[Step]0..*-1[Scenario],
[Scenario]0..*-0..1[Feature]

I confess haven't looked at the Gherkin parser at all yet, but if it
were possible for it to be able to interpret Gherkin text in this way
- looking for features if they're there but not insisting on it, I
think we'd have a better (and more flexible) model.

Having said that, if this would make the Gherkin parser much more
complex, I think we can fix up the few places in Cucumber where we are
taking advantage of this and just add the "Feature: Foo" line.

cheers,
Matt

http://mattwynne.net
+447974 430184

[Matt Wynne]

Better link to the UML:
http://tinyurl.com/yho9arx

[Gregory Hnatiuk]

The syntax policy which describes valid sequences of feature elements
is super easy to change, so implementation isn't a concern. In any
case, I'd be happy to add 'Feature: Foo' where needed in the current
cucumber internals.

There's opportunity (by design, nice work Mike) to define alternate
syntax policies (e.g. bare scenarios allowed, bare steps allowed) in
pure Ruby, as those needs arise, so we didn't feel too bad about
trying to conform strictly the descriptions of Gherkin 'the language'
on the wiki and throughout Cucumber's own features and examples. The
flexibility can definitely be there, it's just not 'on' by default.

Skipping the 'Feature' heading and narrative, as an undocumented
feature of the current Treetop parsing, fell away with the initial
implementation. If it makes sense to promote it to a documented
feature and make it part of the official description of Gherkin
syntax, it would be easy to do now or in the future.

Greg