Scoped step definitions in Cucumber-JVM
aslak hellesoy
request. You still can't do this in Cucumber (Ruby), but now you can
in Cucumber-JVM (currently only with Java):
You simply pass an optional tag expression in addition to the regexp.
We could do something similar for Ruby:
Given(/pattern/, '~@foo') do
end
-Very much in the same way as with tagged hooks. WDYT? The original
ticket is here:
https://rspec.lighthouseapp.com/projects/16211/tickets/531-declarative-mechanism-for-expressing-dependencies-on-step-definitions
Aslak
Joseph Wilk
> Being able to scope step definitions is an old and recurring feature
> request. You still can't do this in Cucumber (Ruby), but now you can
> in Cucumber-JVM (currently only with Java):
>
> https://github.com/cucumber/cucumber-jvm/blob/68d4c668d8a3553c056a15859ab9489ddc6fe629/java/src/test/java/cucumber/runtime/java/JavaStepDefinitionTest.java#L73-86
>
> You simply pass an optional tag expression in addition to the regexp.
> We could do something similar for Ruby:
>
> Given(/pattern/, '~@foo') do
> end
>
> -Very much in the same way as with tagged hooks. WDYT? The original
It makes me a little nervous that the resulting step definitions and
features would become difficult to manage. I remember what Rspec-stories
was like and it produced a mess of step defs.
The number of step definitions by far exceeds the number of Hooks. I
wonder if this is why I've never found a problem managing tagged hooks.
How is this fairing in Java land with maintainable step definitions?
Joe
> ticket is here:
> https://rspec.lighthouseapp.com/projects/16211/tickets/531-declarative-mechanism-for-expressing-dependencies-on-step-definitions
>
> Aslak
>
--
Joseph Wilk
http://blog.josephwilk.net
http://www.songkick.com
+44 (0)7812 816431 | http://twitter.com/josephwilk
Miguel Almeida
Matt Wynne
On 10 Nov 2011, at 11:55, Miguel Almeida wrote:
> However - and personally speaking - I think I am going to try to avoid step definitions with the same text as much as possible, so that step definition management doesn't become too problematic: if a text can mean two things, we might be better off changing the text to something more meaningful.
+1
Richard Lawrence made the point a few weeks ago that having steps defined globally is actually an advantage of Cucumber over, say, fitnesse, because it forces you to use a ubiquitous language. It's one of those features that I used to think would be a good idea, but actually I've found plenty of ways of getting along fine without it.
cheers,
Matt
--
Freelance programmer & coach
Author, http://pragprog.com/book/hwcuc/the-cucumber-book (with Aslak Hellesøy)
Founder, http://relishapp.com
+44(0)7974430184 | http://twitter.com/mattwynne
aslak hellesoy
>
> On 10 Nov 2011, at 11:55, Miguel Almeida wrote:
>
>> However - and personally speaking - I think I am going to try to avoid step definitions with the same text as much as possible, so that step definition management doesn't become too problematic: if a text can mean two things, we might be better off changing the text to something more meaningful.
>
> +1
>
> Richard Lawrence made the point a few weeks ago that having steps defined globally is actually an advantage of Cucumber over, say, fitnesse, because it forces you to use a ubiquitous language. It's one of those features that I used to think would be a good idea, but actually I've found plenty of ways of getting along fine without it.
>
Yeah, I'm a little bit on the fence about it myself - and I *might*
remove it. A ubiquitous language is the goal to strive for, but aren't
there situations where the most natural ubiquitous language can still
have an overloaded meaning depending on context?
The question is - will people misuse this? If so, can anyone think of
examples how it could be (extensively) misused?
Aslak
> cheers,
> Matt
>
> --
> Freelance programmer & coach
> Author, http://pragprog.com/book/hwcuc/the-cucumber-book (with Aslak Hellesøy)
> Founder, http://relishapp.com
> +44(0)7974430184 | http://twitter.com/mattwynne
>
> --
> You received this message because you are subscribed to the Google Groups "Cukes" group.
> To post to this group, send email to cu...@googlegroups.com.
> To unsubscribe from this group, send email to cukes+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/cukes?hl=en.
>
>
Mike Sassak
<aslak.h...@gmail.com> wrote:
> On Thu, Nov 10, 2011 at 5:20 PM, Matt Wynne <ma...@mattwynne.net> wrote:
>>
>> On 10 Nov 2011, at 11:55, Miguel Almeida wrote:
>>
>>> However - and personally speaking - I think I am going to try to avoid step definitions with the same text as much as possible, so that step definition management doesn't become too problematic: if a text can mean two things, we might be better off changing the text to something more meaningful.
>>
>> +1
>>
>> Richard Lawrence made the point a few weeks ago that having steps defined globally is actually an advantage of Cucumber over, say, fitnesse, because it forces you to use a ubiquitous language. It's one of those features that I used to think would be a good idea, but actually I've found plenty of ways of getting along fine without it.
>>
>
> Yeah, I'm a little bit on the fence about it myself - and I *might*
> remove it. A ubiquitous language is the goal to strive for, but aren't
> there situations where the most natural ubiquitous language can still
> have an overloaded meaning depending on context?
>
> The question is - will people misuse this? If so, can anyone think of
> examples how it could be (extensively) misused?
>
I think the biggest opportunity for misuse comes from the tag
expressions themselves. They're confusing to begin with--quick which
one means AND and which OR?--and this will potentially allow people to
construct crazy, multi-clause if/then/else/elsif structures that
determine what mapping implementation is used. Having said that, I
think the ability to pick a different implementation, e.g.
javascript/no-javascript, is a really great feature, but I am not
convinced using tags to do it is the right way.
Mike
Richard Lawrence
> On Thu, Nov 10, 2011 at 5:20 PM, Matt Wynne<ma...@mattwynne.net> wrote:
>> On 10 Nov 2011, at 11:55, Miguel Almeida wrote:
>>
>>> However - and personally speaking - I think I am going to try to avoid step definitions with the same text as much as possible, so that step definition management doesn't become too problematic: if a text can mean two things, we might be better off changing the text to something more meaningful.
>> +1
>>
>> Richard Lawrence made the point a few weeks ago that having steps defined globally is actually an advantage of Cucumber over, say, fitnesse, because it forces you to use a ubiquitous language. It's one of those features that I used to think would be a good idea, but actually I've found plenty of ways of getting along fine without it.
>>
>
> Yeah, I'm a little bit on the fence about it myself - and I *might*
> remove it. A ubiquitous language is the goal to strive for, but aren't
> there situations where the most natural ubiquitous language can still
> have an overloaded meaning depending on context?
>
I've been watching for this since I read the DDD book. I still haven't
seen a case where there were multiple contexts and those contexts were
so related that it made sense to share a set of features. When there's a
clear context boundary with language overloaded between them, I just use
a totally separate set of features and step definitions.
> The question is - will people misuse this? If so, can anyone think of
> examples how it could be (extensively) misused?
>
Feature-coupled steps is the extreme. The more subtle issue is that the
beneficial pressure to grow a ubiquitous language goes away when it
becomes too easy to say, "Oh, that's just another context, I'll use the
same words to mean something different here." Thinking about some of the
conversations I've had coaching teams to learn ubiquitous language, I
would expect this to happen a lot.
I'm hoping the SpecFlow guys will chime in here. They've had this
feature for a while. When we were discussing the SpecFlow Cucumber
harmonization work this summer, we talked about this difference between
SpecFlow and Ruby Cucumber, and they seemed to regret how much scoped
steps get used to avoid growing a ubiquitous language.
Richard
> Aslak
>
>> cheers,
>> Matt
>>
>> --
>> Freelance programmer& coach
>> Author, http://pragprog.com/book/hwcuc/the-cucumber-book (with Aslak Helles�y)
Matt Wynne
On 11 Nov 2011, at 10:03, Richard Lawrence wrote:
> aslak hellesoy wrote:
>> On Thu, Nov 10, 2011 at 5:20 PM, Matt Wynne<ma...@mattwynne.net> wrote:
>>> On 10 Nov 2011, at 11:55, Miguel Almeida wrote:
>>>
>>>> However - and personally speaking - I think I am going to try to avoid step definitions with the same text as much as possible, so that step definition management doesn't become too problematic: if a text can mean two things, we might be better off changing the text to something more meaningful.
>>> +1
>>>
>>> Richard Lawrence made the point a few weeks ago that having steps defined globally is actually an advantage of Cucumber over, say, fitnesse, because it forces you to use a ubiquitous language. It's one of those features that I used to think would be a good idea, but actually I've found plenty of ways of getting along fine without it.
>>>
>>
>> Yeah, I'm a little bit on the fence about it myself - and I *might*
>> remove it. A ubiquitous language is the goal to strive for, but aren't
>> there situations where the most natural ubiquitous language can still
>> have an overloaded meaning depending on context?
>>
>
> I've been watching for this since I read the DDD book. I still haven't seen a case where there were multiple contexts and those contexts were so related that it made sense to share a set of features. When there's a clear context boundary with language overloaded between them, I just use a totally separate set of features and step definitions.
>
>> The question is - will people misuse this? If so, can anyone think of
>> examples how it could be (extensively) misused?
>>
>
> Feature-coupled steps is the extreme. The more subtle issue is that the beneficial pressure to grow a ubiquitous language goes away when it becomes too easy to say, "Oh, that's just another context, I'll use the same words to mean something different here." Thinking about some of the conversations I've had coaching teams to learn ubiquitous language, I would expect this to happen a lot.
>
> I'm hoping the SpecFlow guys will chime in here. They've had this feature for a while. When we were discussing the SpecFlow Cucumber harmonization work this summer, we talked about this difference between SpecFlow and Ruby Cucumber, and they seemed to regret how much scoped steps get used to avoid growing a ubiquitous language.
>
> Richard
I've been coaching a SpecFlow team this week, and I noticed that 'feature' to my distaste. Even the way Given / When / Then steps are separated in Specflow seems like a shame to me.
The more I use and teach BDD / Cucumber, the more I am starting to think that the key benefit is helping the team to discover their own domain language. The tension between documentation and testing is what makes BDD interesting, but it's too easy for it to get pulled too far in the testing direction. Once you lose that balance it stops being nearly so interesting or useful.
cheers,
Matt
--
Freelance programmer & coach
Author, http://pragprog.com/book/hwcuc/the-cucumber-book (with Aslak Hellesøy)
aslak hellesoy
Folks - this is great feedback. I have decided to remove the feature
from Cucumber-JVM.
The obvious fixes are:
* Use more precise / less ambiguous language
* Failing that - delegate to a state machine
Aslak
> cheers,
> Matt
>
> --
> Freelance programmer & coach
> Author, http://pragprog.com/book/hwcuc/the-cucumber-book (with Aslak Hellesøy)
> Founder, http://relishapp.com
> +44(0)7974430184 | http://twitter.com/mattwynne
>
Matt Wynne
Well done for being so opinionated Aslak!
Julien Biezemans
<aslak.h...@gmail.com> wrote:
> On Fri, Nov 11, 2011 at 3:31 PM, Matt Wynne <ma...@mattwynne.net> wrote:
>>
>> On 11 Nov 2011, at 10:03, Richard Lawrence wrote:
>>
>>> aslak hellesoy wrote:
>>>> On Thu, Nov 10, 2011 at 5:20 PM, Matt Wynne<ma...@mattwynne.net> wrote:
>>>>> On 10 Nov 2011, at 11:55, Miguel Almeida wrote:
>>>>>
>>>>>> However - and personally speaking - I think I am going to try to avoid step definitions with the same text as much as possible, so that step definition management doesn't become too problematic: if a text can mean two things, we might be better off changing the text to something more meaningful.
>>>>> +1
>>>>>
>>>>> Richard Lawrence made the point a few weeks ago that having steps defined globally is actually an advantage of Cucumber over, say, fitnesse, because it forces you to use a ubiquitous language. It's one of those features that I used to think would be a good idea, but actually I've found plenty of ways of getting along fine without it.
>>>>>
>>>>
>>>> Yeah, I'm a little bit on the fence about it myself - and I *might*
>>>> remove it. A ubiquitous language is the goal to strive for, but aren't
>>>> there situations where the most natural ubiquitous language can still
>>>> have an overloaded meaning depending on context?
>>>>
>>>
>>> I've been watching for this since I read the DDD book. I still haven't seen a case where there were multiple contexts and those contexts were so related that it made sense to share a set of features. When there's a clear context boundary with language overloaded between them, I just use a totally separate set of features and step definitions.
>>>
>>>> The question is - will people misuse this? If so, can anyone think of
>>>> examples how it could be (extensively) misused?
>>>>
>>>
>>> Feature-coupled steps is the extreme. The more subtle issue is that the beneficial pressure to grow a ubiquitous language goes away when it becomes too easy to say, "Oh, that's just another context, I'll use the same words to mean something different here." Thinking about some of the conversations I've had coaching teams to learn ubiquitous language, I would expect this to happen a lot.
>>>
>>> I'm hoping the SpecFlow guys will chime in here. They've had this feature for a while. When we were discussing the SpecFlow Cucumber harmonization work this summer, we talked about this difference between SpecFlow and Ruby Cucumber, and they seemed to regret how much scoped steps get used to avoid growing a ubiquitous language.
>>>
>>> Richard
>>
>> I've been coaching a SpecFlow team this week, and I noticed that 'feature' to my distaste. Even the way Given / When / Then steps are separated in Specflow seems like a shame to me.
>>
>> The more I use and teach BDD / Cucumber, the more I am starting to think that the key benefit is helping the team to discover their own domain language. The tension between documentation and testing is what makes BDD interesting, but it's too easy for it to get pulled too far in the testing direction. Once you lose that balance it stops being nearly so interesting or useful.
>>
>
> Folks - this is great feedback. I have decided to remove the feature
> from Cucumber-JVM.
That's an interesting thread, indeed. I'm glad this feature is going
to vanish as it was a pandora's box. I second Richard's wise words on
the potential threat to the ubiquitous language.
Cheers,
-- Julien.
> The obvious fixes are:
>
> * Use more precise / less ambiguous language
> * Failing that - delegate to a state machine
>
> Aslak
>
>> cheers,
>> Matt
>>
>> --
>> Freelance programmer & coach
>> Author, http://pragprog.com/book/hwcuc/the-cucumber-book (with Aslak Hellesřy)