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?
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.
On Thu, Oct 22, 2009 at 1:35 PM, Mike Sassak <msas...@gmail.com> wrote:
> 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?
> 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.
> On Thu, Oct 22, 2009 at 1:35 PM, Mike Sassak <msas...@gmail.com> wrote:
>> 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?
> On Thu, Oct 22, 2009 at 6:02 PM, Richard Lawrence
> <rich...@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:
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.
> Thanks for the heads up! I'll make sure to let you know if you can't
> depend on the bare scenarios any more.
>> Richard
>> On Thu, Oct 22, 2009 at 1:35 PM, Mike Sassak <msas...@gmail.com>
>> wrote:
>>> 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?
>> On Thu, Oct 22, 2009 at 6:02 PM, Richard Lawrence
>> <rich...@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:
> 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.
>> Thanks for the heads up! I'll make sure to let you know if you can't
>> depend on the bare scenarios any more.
>>> Richard
>>> On Thu, Oct 22, 2009 at 1:35 PM, Mike Sassak <msas...@gmail.com>
>>> wrote:
>>>> 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?
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.
On Sat, Oct 24, 2009 at 10:34 AM, Matt Wynne <m...@mattwynne.net> wrote:
> On 24 Oct 2009, at 15:26, Matt Wynne wrote:
>> On 22 Oct 2009, at 23:23, Mike Sassak wrote:
>>> On Thu, Oct 22, 2009 at 6:02 PM, Richard Lawrence
>>> <rich...@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:
>> 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.
>>> Thanks for the heads up! I'll make sure to let you know if you can't
>>> depend on the bare scenarios any more.
>>>> Richard
>>>> On Thu, Oct 22, 2009 at 1:35 PM, Mike Sassak <msas...@gmail.com>
>>>> wrote:
>>>>> 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?
