Is there a way for a step to get hold of the current scenario and/or the actual step definition?

[Simon Harris]

I'd like to know if the step is being executed as a When vs a Given vs
a Then, etc. but when I try to use different matching steps I get an
error because the names of the steps are identical.

[Aslak Hellesøy]

Can you give a concrete example please?

Aslak

> --
> 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.
>

[Simon Harris]

On Feb 18, 10:44 am, Aslak Hellesøy <aslak.helle...@gmail.com> wrote:

> On Feb 17, 2011, at 23:42, Simon Harris <haruki_zae...@mac.com> wrote:
>
> > I'd like to know if the step is being executed as a When vs a Given vs
> > a Then,
> > etc. but when I try to use different matching steps I get an
> > error because the names of the steps are identical.
>
> Can you give a concrete example please?

When /^(.*)$/ do |text|
...
end

Given /^(.*)$/ do |text|
...
end

By design this will give you a conflict but I'd like to be able to
distinguish between the two.

I've tried building a formatter as that has access to the step
definition but, quite rightly, no access to the World.

I've managed to "hack" together something that works but I'd like to
make it nicer. What I've done is to effectively create a Manual step
runner that asks if the step succeeded or failed but to do so requires
knowledge of the original step keyword, which I don't have access to
in steps themselves but I do have access to in a formatter. But a
formatter can't fail a step. Catch-22.

So I've hacked together some really BAD global communication and it
works, gets me going, but I'd like to NOT have to make it so awful and
likely to fail in the future.

[Rob Hunter]

The way I tend to write steps, the grammar disambiguates Given/When/Then:

Given a statement is true

When an actor acts

Then a condition should hold

I'd love to know the grammatical names for these formats -- passive simple, active simple? Double subjunctive hyper-perfect continuous?

Examples of the disambiguation:

Given my basket contains 10 items

When I add 10 items to my basket

Then my basket should contain 10 items

Given grapes are discounted

When the manager discounts grapes

Then grapes should be discounted

Given I am logged in

When I log in

Then I should be logged in

Given it is Monday

When I wait until Monday

Then it should be Monday

This grammatical style works well enough for me that I'd like to formalise it. Is this pattern as common as it seems? Does anyone have a name for it already?

-- 

Rob Hunter

(Sent from my phone)

[Simon Harris]

Sure, my issue is about printing the steps out rather than anything
else and a step definition can't get access to the original text so I
had to come up with a hybrid that uses a Formatter as well as a
generic step definition.

On Feb 18, 8:50 pm, Rob Hunter <robertjhun...@gmail.com> wrote:

[Simon Harris]

> > I get an
> > error because the names of the steps are identical.

I probably should clarify this. I don't mean the names of the steps
themselves, but the patterns used to match are identical.

[Matt Wynne]

I think Aslak's looking for a concrete example of why you need it, not how you've implemented it.

>
> --
> 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.
>

cheers,
Matt

ma...@mattwynne.net
07974 430184

[Richard Lawrence]

You've figured out that you can't get the keyword in a step
definition. AFAIK, no one will be able to tell you otherwise. Perhaps
if you could explain *why* you want to solve that problem (e.g. with
examples that illustrate the why as well as the what—your earlier
example only did the latter for me), we might be able to suggest an
alternative approach.

Best,

Richard

[Simon Harris]

I don't know how I could have been more concrete:

"What I've done is to effectively create a Manual step
runner that asks if the step succeeded or failed but to do so requires
knowledge of the original step keyword, which I don't have access to
in steps themselves but I do have access to in a formatter. But a
formatter can't fail a step. Catch-22."

Simon Harris
--
w: http://www.harukizaemon.com/
e: haruki...@mac.com
m: +61 417 505 611
t: @haruki_zaemon

[Simon Harris]

> I think Aslak's looking for a concrete example of why you need it, not how you've implemented it.

I'm not sure how I could have been more concrete than:

[Matt Wynne]

On 18 Feb 2011, at 19:42, Simon Harris wrote:

> I don't know how I could have been more concrete:
>
> "What I've done is to effectively create a Manual step
> runner that asks if the step succeeded or failed but to do so requires
> knowledge of the original step keyword, which I don't have access to
> in steps themselves but I do have access to in a formatter. But a
> formatter can't fail a step. Catch-22."

This sounds interesting. Is the code public? Want to show us? I'm sure we can help.

[Rob Hunter]

On 18/02/2011, at 1:53 PM, Simon Harris <haruki...@mac.com> wrote:
> What I've done is to effectively create a Manual step runner that asks if the step succeeded or failed

Are you saying you've built support mixing automated and non-automated steps in a single scenario, where the manual results still show up in reports?

I've been interested in such a feature for a while. I expected to implement it on a per-step basis, something like:

Then /^the printed output should be readable$/ do
human_assert 'Check the printer. The output should be free of "missing font" squares.'
end

In this example, human_assert would wait for a human to give pass/fail/error choice based on the instructions.

Is that the kind of thing you're talking about? Except it sounds like your solution goes further and handles any unimplemented step.

I suspect that the current Cucumber code doesn't provide a nice hook for an "unimplemented step handler". In my situation, I'm not sure I'd want to handle *all* unimplemented steps; I'd probably restrict it by tag like @some-manual-steps or @needs-a-human.

[Matt Wynne]

On 18 Feb 2011, at 22:23, Rob Hunter wrote:

> On 18/02/2011, at 1:53 PM, Simon Harris <haruki...@mac.com> wrote:
>> What I've done is to effectively create a Manual step runner that asks if the step succeeded or failed
> Are you saying you've built support mixing automated and non-automated steps in a single scenario, where the manual results still show up in reports?
>
> I've been interested in such a feature for a while. I expected to implement it on a per-step basis, something like:
>
> Then /^the printed output should be readable$/ do
> human_assert 'Check the printer. The output should be free of "missing font" squares.'
> end

There is already #ask which does exactly this.

>
> In this example, human_assert would wait for a human to give pass/fail/error choice based on the instructions.
>
> Is that the kind of thing you're talking about? Except it sounds like your solution goes further and handles any unimplemented step.
>
> I suspect that the current Cucumber code doesn't provide a nice hook for an "unimplemented step handler". In my situation, I'm not sure I'd want to handle *all* unimplemented steps; I'd probably restrict it by tag like @some-manual-steps or @needs-a-human.
>
>

> --
> 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.
>

cheers,
Matt

ma...@mattwynne.net
07974 430184

[Simon Harris]

For my needs ALL steps are manual but it could easily be done based on say an @manual tag. There is no way, that I can see, to detect unimplemented steps so I put in a catch-all. I also just use the step text as the prompt and ask for a Success, Fail, or Pending.

I'll put the code up on GitHub. It's kinda trivial really but could be made better with some framework support.

I also want to track the tests that have failed most recently/frequently and have them run first. Being manual tests that will make a big difference. Is there already something to do that?

[Simon Harris]

>>> What I've done is to effectively create a Manual step runner that asks if the step succeeded or failed
>> Are you saying you've built support mixing automated and non-automated steps in a single scenario, where the manual results still show up in reports?
>>
>> I've been interested in such a feature for a while. I expected to implement it on a per-step basis, something like:
>>
>> Then /^the printed output should be readable$/ do
>> human_assert 'Check the printer. The output should be free of "missing font" squares.'
>> end
>
> There is already #ask which does exactly this.

Yes, that's what I've used. I'll put the code (such that there is) on GitHub today.

[Rob Hunter]

On 19/02/2011, at 11:40 AM, Matt Wynne <ma...@mattwynne.net> wrote:

>
> On 18 Feb 2011, at 22:23, Rob Hunter wrote:
>
>> On 18/02/2011, at 1:53 PM, Simon Harris <haruki...@mac.com> wrote:
>>> What I've done is to effectively create a Manual step runner that asks if the step succeeded or failed
>> Are you saying you've built support mixing automated and non-automated steps in a single scenario, where the manual results still show up in reports?
>>
>> I've been interested in such a feature for a while. I expected to implement it on a per-step basis, something like:
>>
>> Then /^the printed output should be readable$/ do
>> human_assert 'Check the printer. The output should be free of "missing font" squares.'
>> end
>
> There is already #ask which does exactly this.

Really? I thought Twist was currently unique in mixing manual and automated steps. Very glad to know I'm wrong :-) I'm going to start using the *heck* out of that feature!

[Simon Harris]

>> There is already #ask which does exactly this.
>
> Really? I thought Twist was currently unique in mixing manual and automated steps. Very glad to know I'm wrong :-) I'm going to start using the *heck* out of that feature!

But #ask doesn't fail it just, you know, asks and returns the answer.

[Matt Wynne]

To fail a step definition, you just raise an exception. So check what came back from #ask, and raise an exception if you don't like it. For example:

raise("FAIL") unless ask("Did it work?") == "yes"

Or better, using an rspec assertion:

ask("Did it work?").should == "yes"

[Simon Harris]

>>>> There is already #ask which does exactly this.
>>>
>>> Really? I thought Twist was currently unique in mixing manual and automated steps. Very glad to know I'm wrong :-) I'm going to start using the *heck* out of that feature!
>>
>> But #ask doesn't fail it just, you know, asks and returns the answer.
>
> To fail a step definition, you just raise an exception. So check what came back from #ask, and raise an exception if you don't like it. For example:
>
> raise("FAIL") unless ask("Did it work?") == "yes"
>
> Or better, using an rspec assertion:
>
> ask("Did it work?").should == "yes"

Indeed, this last example is what I am doing. I just wanted Rob to know that #ask didn't replace the need for assertion -- which he had encapsulated in one call in his original example.

[Robert]

Is the use of #ask supported in Cuke4Duke?  I am currently using version 0.3.2 of Cuke4Duke and version 0.8.5 of Cucumber.  If it is possible, could you provide a sample code snippet along with a sample scenario? Thanks.