Matching method name through regexp and executing it

[Vlad Wbox]

Hi! I have my screen steps defined like that:(matching hash key and accessing hash values)

When /^I (?:am on|see) "([^\"]*)" screen$/ do |screen|

  $screens_hash[screen]

end

then I have a objectsrepo.rb file with screens hash like i.e.:

$screens_hash={

"Create PIN" => create_pin_screen(),

"Confirm PIN" => confirm_pin_screen(),

         ...

}

 

I am trying to use method names as values.

Then methods are defined in a Screen_helpers.rb file in a module like this:

module Screens_helpers

def confirm_new_pin_screen()

$hash1.values_at(

    "Confirm New PIN",

    "Delete",

    "Cancel",

  ).each do |x|

    wait_for(WAIT_TIMEOUT) { element_exists(x)}

  end

end

end

When I execute the step I get  "undefined method `create_pin_screen' for main:Object (NoMethodError)"

Is there a way or a better way to do that?

Thanks!

[Andrew Premdas]

I don't understand why you want to do this. Why not just use KISS and write a step def for each screen. Is it really that much work?

Secondly what are your create_xxx_screen methods trying to do. Surely you should just be going to a URL.

Finally those When's should be Given's. They are setup things, the when would be what you do when you are at that screen.

All best

Andrew

--
Posting rules: http://cukes.info/posting-rules.html
---
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/d/optout.

--

------------------------

Andrew Premdas

blog.andrew.premdas.org

[Vlad Wbox]

What is KISS? :)

I had step definitions before like:

 When /^I am on this screen$/ do

this_method()

end

 Screens  are native app screens, not URL"s, method is basically checking that all elements are present on the screen and some other things depending on the screen.

I just was looking for a way to write a single step definition like below and link variable screen_name to corresponding method using hash or smth like that.

When /^I am on "([^\"]*)" screen$/ do |screen_name|

  find_and_execute_method_"screen_name"

end

 

[Andrew Premdas]

KISS = keep it simple stupid 

You might be better using a unit test tool for these sort of things.

Using cukes I would stick with a single step definition for each screen, its much simpler. You shouldn't worry about trying to be super efficient with writing step definitions. 10 simple step defs are much better than 1 highly complex one.

Personally I would write the scenarios as

Scenario: Foo screen has correct elements

  Given I am on the foo screen

  Then I should see foo elements

And be quite happy to write single step definitions for each one e.g.

Given 'I am on the foo screen' do

  go_to foo_screen

  # or

  go_to_foo_screen

end

Then 'I should see foo elements' do

  should_see foo_elements

  # or

  should_see_foo_elements

end

I'd only think about code efficiency/reuse once I get into my helper methods.

Fundamental to this approach is the idea that step definitions should only be used for translating natural language to calls, they should not do anything else. If this is all they do, you gain nothing much by minimizing their number (all you are doing is restricting the vocabulary you can use in your features.

Hope that helps

All best

Andrew

--

Posting rules: http://cukes.info/posting-rules.html
---
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/d/optout.

[Roberto Lo Giacco]

Il giorno giovedì 14 gennaio 2016 04:25:17 UTC+1, apremdas ha scritto:

Scenario: Foo screen has correct elements

  Given I am on the foo screen

  Then I should see foo elements

Another way to write the above scenario giving the reader more insights about the elements on screen (which might be valuable) is

Scenario:Foo screen has correct elements
 Given

I am on the foo screen
 Then I should see all the following elements
   | foo   | required |

   | bar   | optional |
   | some  | required |
   | other | select   |

That, in my humble opinion, brings value to the reader while still keeping the scenario readable and the associated step def assertable.You don't have to implement all the assertions in the stepdef, as an example you might decide to avoid testing the field type (required, optional, select) and just test for its presence, at the same time though you are capturing the field constraints for the developers to implement.