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.
>
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
Best,
Richard
"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
I'm not sure how I could have been more concrete than:
> 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.
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.
> 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
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?
Yes, that's what I've used. I'll put the code (such that there is) on GitHub today.
>
> 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!
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.