Re: [Cucumber] [JVM] How do steps know their feature?

[aslak hellesoy]

On Wed, May 15, 2013 at 9:38 AM, <pinus...@gmail.com> wrote:

I currently need to find the feature a step belongs to.

First of all - it sounds like you are conflating Gherkin "steps" [1] and Ruby/Java/programming language X "step definitions" [2]. That makes it difficult to understand what you mean.

[1] https://github.com/cucumber/cucumber/wiki/Given-When-Then

[2] https://github.com/cucumber/cucumber/wiki/Step-Definitions

I have a Feature, a Scenario and Steps.

Steps might be called in different contexts, e.g. the login step is called in multiple features.

Now the login step needs to know which feature "called" it.

Why do you need to know this? Think of step definitions as methods. Methods don't need to know who called them and neither do step definitions.

 

Since the feature file is scanned line by line, the information should be available somewhere.

Where is this information?

It's not available to you.

Aslak

--
-- Rules --
 
1) Please prefix the subject with [Ruby], [JVM] or [JS].
2) Please use interleaved answers http://en.wikipedia.org/wiki/Posting_style#Interleaved_style
3) If you have a question, don't reply to an existing message. Start a new topic instead.
 
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 https://groups.google.com/d/forum/cukes?hl=en
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Tim Walker]

Further, a step might be reused in several features. 

[aslak hellesoy]

On Wed, May 15, 2013 at 10:02 AM, Tim Walker <walk...@gmail.com> wrote:

Further, a step might be reused in several features. 

I think you meant "a step definition might be reused in several features".

Aslak

[Tim Walker]

Indeed I did. Thank you. 

[pinus...@gmail.com]

Am Mittwoch, 15. Mai 2013 16:46:38 UTC+2 schrieb Aslak Hellesøy:

On Wed, May 15, 2013 at 9:38 AM, <pinus...@gmail.com> wrote:

I currently need to find the feature a step belongs to.

First of all - it sounds like you are conflating Gherkin "steps" [1] and Ruby/Java/programming language X "step definitions" [2]. That makes it difficult to understand what you mean.

[1] https://github.com/cucumber/cucumber/wiki/Given-When-Then

[2] https://github.com/cucumber/cucumber/wiki/Step-Definitions

I have a Feature, a Scenario and Steps.

Steps might be called in different contexts, e.g. the login step is called in multiple features.

Now the login step needs to know which feature "called" it.

Why do you need to know this? Think of step definitions as methods. Methods don't need to know who called them and neither do step definitions.

Yes I mean the Gherkin steps. The Gherkin language is supposed to be a management compatible language to describe tests.

Step definitions are more functions than methods and that's exactly the problem. Functions need parameters, usually a lot of them.

For the login example this is at least the user and the password. And you easily have additional parameters like the URL the language or the default font.If you have your Gherkin file cluttered with this information the readability suffers.

Our solution is either hard coded (not reusable) or with a property file, which is also not reusable because you have only one file.

My idea was to load the properties hierarchically, Feature properties overwrite, Scenario properties which overwrite default properties. This would enable different sets of parameters for a step definition, depending on the calling feature. But this requires that the step definition knows about it's feature.  

 

 

Since the feature file is scanned line by line, the information should be available somewhere.

Where is this information?

It's not available to you.

 Well, why not? How do you reuse step definitions which require complex set of parameters?

[Andrew Premdas]

You don't, you refactor so they have a simple set of parameters - none of my step definitions have more than 2 parameters and most have none at all. You achieve this by 'pushing the how down' and applying general programming techniques.

You shouldn't think of step definitions as functions or methods (even though they are), instead think of them as the translation layer that connects your Gherkin to your automation code. Their only job is to make this connection. So in general any step definition can be

"My step definition with any number of params" do | params |

    call_method(params)

end

If you use step definitions in this manner, you can keep things simple. Once you have passed through the translation layer you can organise the underlying `code` however you like to deal with the complexity of your context. 

--

[pinus...@gmail.com]

Am Donnerstag, 16. Mai 2013 10:44:39 UTC+2 schrieb apremdas:

On 16 May 2013, at 07:57, pinus...@gmail.com wrote:

Am Mittwoch, 15. Mai 2013 16:46:38 UTC+2 schrieb Aslak Hellesøy:

On Wed, May 15, 2013 at 9:38 AM, <pinus...@gmail.com> wrote:

I currently need to find the feature a step belongs to.

First of all - it sounds like you are conflating Gherkin "steps" [1] and Ruby/Java/programming language X "step definitions" [2]. That makes it difficult to understand what you mean.

[1] https://github.com/cucumber/cucumber/wiki/Given-When-Then

[2] https://github.com/cucumber/cucumber/wiki/Step-Definitions

I have a Feature, a Scenario and Steps.

Steps might be called in different contexts, e.g. the login step is called in multiple features.

Now the login step needs to know which feature "called" it.

Why do you need to know this? Think of step definitions as methods. Methods don't need to know who called them and neither do step definitions.

Yes I mean the Gherkin steps. The Gherkin language is supposed to be a management compatible language to describe tests.

Step definitions are more functions than methods and that's exactly the problem. Functions need parameters, usually a lot of them.

For the login example this is at least the user and the password. And you easily have additional parameters like the URL the language or the default font.If you have your Gherkin file cluttered with this information the readability suffers.

Our solution is either hard coded (not reusable) or with a property file, which is also not reusable because you have only one file.

My idea was to load the properties hierarchically, Feature properties overwrite, Scenario properties which overwrite default properties. This would enable different sets of parameters for a step definition, depending on the calling feature. But this requires that the step definition knows about it's feature.  

 

 

Since the feature file is scanned line by line, the information should be available somewhere.

Where is this information?

It's not available to you.

 Well, why not? How do you reuse step definitions which require complex set of parameters?

You don't, you refactor so they have a simple set of parameters - none of my step definitions have more than 2 parameters and most have none at all. You achieve this by 'pushing the how down' and applying general programming techniques.

Sorry, but I don't understand. If you are allowed to have one parameter in the login example. The parameter is the user, where did you get the password information from? Now you want to use the same login step definition to test several applications with the same login screen.

The only option I see is that you DO NOT reuse the step definitions. You use the step definitions to store the values and separate it from the executing code. To test 5 applications I would need 5 step definitions and a class with the login code.

And then testing the login in 20 languages...

For me this looks like lots of glue code.