Printing nested steps to output
Boeboe
I have been looking for a solution to print nested steps, like
suggested in https://rspec.lighthouseapp.com/projects/16211-cucumber/tickets/661-option-to-list-nested-steps#ticket-661-2.
The reason why this is needed, is once you have a nesting level of
more then 3, it becomes harder to find out where your scenario really
failed. At
http://groups.google.com/group/cukes/browse_thread/thread/9538d55a07c67f6d/a0395e4c13e05888?lnk=gst&q=nested#a0395e4c13e05888
I found a suggestion to encapsulate nested steps in traditional ruby
methods, but I don't know if this is really the way I want to go.
Furthermore I have been trying to look at the formatters provided to
see of there is a place to easily add this functionality but I did not
find an easy hack.
In step_mother I found two methods nested! and nested?, but
unfortunately they are not called when entering a nested step.
Anyone some idea's on how to get around this restriction? The end
result I'd like to have is something like:
Given I am logged in
Then I go to page "bla.com"
Then I should see text "login"
Then I fill in username with "me"
Then I fill in password with "noway"
Then I press button "submit"
Then I create a user "jefke"
Then I should be logged in
Then I go to page "create_user"
Then I click link "menu"
Then I click link "create user"
Then I should see text "create user"
Then I fill in "new_user' with "new"
Then I go to page "view user"
...
...
...
When I create a user and it fails because the link "create user" was
not available, I'd like to see all successful steps and sub-steps, up
until he one that failed. As long as your steps are just encapsulating
one or two actions, this is not a huge problem. Once you start
refactoring your steps to stay DRY, you readability from the running/
successful steps is lost.
Kindly,
Bart
Mike Sassak
Hi Bart,
I think you mentioned above the solution most people come to: using
helper methods defined in the World rather than deeply nesting steps.
In my experience using helpers is much more maintainable than deeply
nested steps, and I'm sure I'm not alone on that point. Is there a
reason you're unsure about using World helpers?
Mike
>
> Kindly,
> Bart
>
> --
> 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.
>
>
EMoreth
I really dont know how to use these global helpers (I'll take a look
into that as soon as I can), but I often use nested steps for
repetitive long sequence of steps. I mean, my app has lots of huge
forms that nests User info, project info and schedule info, so I have
my tests to test the user info and the project info, but when I
started to test schedule info (90% of the tests), I got into a lot of
copy-pasted "And I fill THIS with THAT" from the previous tests.
To solve that non-DRY issue I nested all those steps on "And I fill
all the default info".
As it is a big app, running all tests usually takes 10~12 minutes on
my machine, so I usually run just the feature I'm working on.
The point is that whenever a nested step breaks, I need to go search
the file which has that steps implemented to find in what point the
feature was broken.
Have an option (even if not a default option, for performance isssues
I think) would be great. Because when running all features, at least
one would warn me about where that error occurs, but thats not what I
do in most of cases.
EMoreth
On Sep 30, 1:13 pm, Mike Sassak <msas...@gmail.com> wrote:
> > Hi all,
>
> > I have been looking for a solution to print nested steps, like
> > The reason why this is needed, is once you have a nesting level of
> > more then 3, it becomes harder to find out where your scenario really
> > failed. At
Boeboe
I have not been looking into Worlds myself until now. I've tumbled
into Cucumber through Capybara for driving Web Automated tests, so I
did not take the time to investigate Cucumber deep enough. I'll take a
look at Worlds as soon as possible. Do you have any nice posts to
share of use cases that solved the issue I have with Worlds, as
introductory material?
Kindly thanks,
Bart
Mike Sassak
> Hi both,
>
> I have not been looking into Worlds myself until now. I've tumbled
> into Cucumber through Capybara for driving Web Automated tests, so I
> did not take the time to investigate Cucumber deep enough. I'll take a
> look at Worlds as soon as possible. Do you have any nice posts to
> share of use cases that solved the issue I have with Worlds, as
> introductory material?
>
Hi,
WIth only a small exaggeration, if you're not extending the World,
you're missing out on half of Cucumber. :-)
The wiki is helpful, as usual. These links should help get you started
* http://github.com/aslakhellesoy/cucumber/wiki/A-Whole-New-World
* http://drnicwilliams.com/2009/04/15/cucumber-building-a-better-world-object/
Mike
Bart Van Bos
Mike Sassak
> Hi Mike,
> Until now our helper methods (none Capybara / Cucumber related) are located
> in modules we require through env.rb. So far I've read the two posts about
> extending the Cucumber World, by defining you own World and loading it.
> However I do not see any relation with this and the logging of nested steps.
> Extending Worlds seems a nicer way to integrate our general helper methods,
> so thanks for the tip already. But are you suggesting to define all steps
> (read: all steps that use other steps) in an extra World class? What about
> debugging/output of World methods towards STDOUT or your favorite formatter?
Hi Bart,
In your original email you said that debugging nested steps becomes
difficult when they are nested deeply. I suggested using extensions to
the World rather than nested steps, as the former are in my experience
far easier to debug and maintain than deeply nested steps. (Say nested
deeper than 1 level.) In other words, avoid nesting steps almost
entirely and start thinking of how to accomplish the same with "plain
old Ruby"--you can do everything in World extension modules that you
can in step definitions and more. Think of the step definitions
themselves as a very thin translation layer between the requirements
of your application expressed in natural language (in the feature
files) and a "World" layer written in the implementation language that
places your app into a certain state and then verifies that state
against expectations. If you're using Rails perhaps you've heard the
saying "Skinny Controller, Fat Model". Something kind of similar
applies to step definitions and extensions to World.
HTH,
Mike
George Dinwiddie
On 9/30/10 6:47 PM, Mike Sassak wrote:
> In your original email you said that debugging nested steps becomes
> difficult when they are nested deeply. I suggested using extensions to
> the World rather than nested steps, as the former are in my experience
> far easier to debug and maintain than deeply nested steps. (Say nested
> deeper than 1 level.) In other words, avoid nesting steps almost
> entirely and start thinking of how to accomplish the same with "plain
> old Ruby"--you can do everything in World extension modules that you
> can in step definitions and more. Think of the step definitions
> themselves as a very thin translation layer between the requirements
> of your application expressed in natural language (in the feature
> files) and a "World" layer written in the implementation language that
> places your app into a certain state and then verifies that state
> against expectations. If you're using Rails perhaps you've heard the
> saying "Skinny Controller, Fat Model". Something kind of similar
> applies to step definitions and extensions to World.
Certainly this is one way to do things, but it's at odds with Cucumber
as an enabler of functional specification by non-programmers. I counsel
testers to take their imperative tests and push them down into step
definitions written in gherkin. As they do so, there seems to naturally
be multiple levels of these. And debugging mistakes seems to be the
biggest difficulty.
I think it's worth exploring what we can do better, here. Otherwise we
run the risk of creating yet another tool that speaks to the
programmers, but asks the testers and business people to take it on faith.
- George
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
Mike Sassak
Hi George,
Can you elaborate on these points? I don't see how using moving
commonly-used functionality into extensions to the World would prevent
non-programmers from writing scenarios in Gherkin. The step names will
remain written in natural language--no problem for non-programmers
there--and most helpers are simple, imperative code as well.
Mike
> - George
>
> --
> ----------------------------------------------------------------------
> * George Dinwiddie * http://blog.gdinwiddie.com
> Software Development http://www.idiacomputing.com
> Consultant and Coach http://www.agilemaryland.org
> ----------------------------------------------------------------------
>
Boeboe
I think when you choose to use World extensions, you'll loose a lot of
the handy things from formatters, since nested steps are not as normal
step calls in a scenario (which is loaded into a new World object for
every feature). And how do I choose to put a step in a world extension
or one in the normal step_definitions? It just does not feel right to
start splitting op your step population.
BR
Bart
PS: to George: testers should be good programmers or at least have
some skills for it. Please don't take them under the same umbrella is
business people as it comes to faith in SW tools, it breaks my hard. I
have been writing test SW whole my professional life until now, you
know :)
Matt Wynne
On 2 Oct 2010, at 13:41, George Dinwiddie wrote:
> Mike, et al,
>
> On 9/30/10 6:47 PM, Mike Sassak wrote:
>> In your original email you said that debugging nested steps becomes
>> difficult when they are nested deeply. I suggested using extensions to
>> the World rather than nested steps, as the former are in my experience
>> far easier to debug and maintain than deeply nested steps. (Say nested
>> deeper than 1 level.) In other words, avoid nesting steps almost
>> entirely and start thinking of how to accomplish the same with "plain
>> old Ruby"--you can do everything in World extension modules that you
>> can in step definitions and more. Think of the step definitions
>> themselves as a very thin translation layer between the requirements
>> of your application expressed in natural language (in the feature
>> files) and a "World" layer written in the implementation language that
>> places your app into a certain state and then verifies that state
>> against expectations. If you're using Rails perhaps you've heard the
>> saying "Skinny Controller, Fat Model". Something kind of similar
>> applies to step definitions and extensions to World.
>
> Certainly this is one way to do things, but it's at odds with Cucumber as an enabler of functional specification by non-programmers. I counsel testers to take their imperative tests and push them down into step definitions written in gherkin. As they do so, there seems to naturally be multiple levels of these. And debugging mistakes seems to be the biggest difficulty.
Certainly the way Cucumber is right now, I really would try to suggest that at that point, the tester goes to the original (imperative) step definition that they want to re-use within this other step definition, and extracts whatever contents it has into a helper method, then replaces use of the imperative step definition with a call to that method. Otherwise, apart from the specific debugging problem highlighted here, you have an unnecessary amount of indirection, and more complex dependencies going on in your codebase.
I think Mike also mentioned this, and I'm very much coming around to the opinion that the step definitions should be a very thin layer over a set of Ruby helpers that do all the hard work *in your domain language*. So rather than calling fill_in, click_button etc, they say log_in_as, and let that helper do all the hard work. To that end, I think it's important to help testers to feel comfortable extracting and creating their own Ruby methods.
I tried to talk about this in a blog post recently:
It sounds like you have a different perspective though. Do you think I'm going off in the wrong direction here?
> I think it's worth exploring what we can do better, here. Otherwise we run the risk of creating yet another tool that speaks to the programmers, but asks the testers and business people to take it on faith.
So are you saying that it would be useful to you to have a business-friendly way (i.e. more Gherkin than Ruby) to map an abstract step to a series of - more imperative - step definitions?
>
> - George
>
> --
> ----------------------------------------------------------------------
> * George Dinwiddie * http://blog.gdinwiddie.com
> Software Development http://www.idiacomputing.com
> Consultant and Coach http://www.agilemaryland.org
> ----------------------------------------------------------------------
>
> --
> 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
Matt Wynne
On 3 Oct 2010, at 17:37, Matt Wynne wrote:
> I tried to talk about this in a blog post recently:
Sorry, forgot the link.
http://blog.mattwynne.net/2010/08/31/outside-in-vs-inside-out-comparing-tdd-approaches/
George Dinwiddie
Let's look at a typical scenario. The tester starts out with a series
of imperative steps: enter this text in this field, check this checkbox,
click this button. These are a natural place to start, particularly for
a tester new to automation.
I then counsel them to push these actions down into step definitions
written in Gherkin. Now they have steps such as "login as <user>,"
"search for <partial name>," "add <product name> to cart," and "submit
order." These steps are still of the imperative style, but written in
terms of the application, rather than in terms of the implementation
details.
On top of that, we can build more declarative step declarations such as
"Given I have the following books in my cart" and "When I purchase using
a valid VISA card."
As a programmer, I can rewrite the lower steps in ruby, but I'm not sure
it's a good idea to do so. For non-programmers, it's now a leap of
faith that the test does what they think it does.
Matt Wynne
OK I'm with you I think. So the leap of faith comes when they switch from implementing the step definition using #steps to call other step definitions in gherkin, to implementing it using Ruby methods? Even Ruby methods like fill_in, click_button etc?
George Dinwiddie
Yes, some business people are highly allergic to something that looks
like code. But from another point of view, why should I rewrite my
working gherkin steps in ruby?