luke-hill on bundler
luke-hill on main
Development updates (#552) - U… (compare)
Scenario:
Given we are working with the number "7"
Then we can do stuff with it
And even more stuff
Given /^we are working with the number "(\d+)"$/ do |number|
@current_number = number
end
Then /^we can do stuff with it$/ do
puts "Doing stuff with #{@current_number}"
end
Then /^even more stuff$/ do
puts "Doing more stuff with #{@current_number}"
end
Given/When/And/etc.
are ignored and only the freeform part of the statement is considered.
binding.pry
but fails when run as part of my Ruby step file. Any advice? [10] pry(#<Cucumber::Rails::World>)> page.first('a', text: "edit")
=> #<Capybara::Node::Element tag="a" path="/html/body/div[2]/div/div/div/div[2]/form/div[4]/p[2]/div/div/div/div/div/table/tr[2]/td[3]/a">
[11] pry(#<Cucumber::Rails::World>)> page.first('a', text: "edit").click
=> Obsolete #<Capybara::Node::Element>
[12] pry(#<Cucumber::Rails::World>)>
binding.pry
then your code is presumably the same as when you run a test because you are running a test. So my guess is that it is a timing issue.
binding.pry
with a sleep 5
, does it work? Is the page not done moving around and it is working in pry
because it has extra time before you start typing things at it?
sleep
a good solution for timing issues.
@here I know Backgrounds
apply to all Scenarios
in a Feature
file, but I'm curious if there's a way to get around this so it doesn't apply to all the scenarios.
Example:
I have users with different permissions to access the application. Instead of creating 2 different feature files for the same feature to account for permissions, I'd rather have a background handle logging in for these 2 different users.
Feature: Ability to log into the application with users with different permissions.
Background_1: User with Admin Permissions
Scenario: As an admin user I log in and see the admin link
Background_2: User without Admin Permissions
Scenario: As a user I log in and do not see the admin link
Looks like this conversation has occurred in the past: cucumber-attic/gherkin#41 and I'm not sure if there was a resolution.
I am trying hard to reduce the number of feature files I need to create because I have to accommodate permissions.
I'm some would argue that 2 features files should be required because testing the Application and Features with different permissions does create the features to be in a different state.
but this goes more towards your structure of tests
ideally, the scenarios will be self contained and not dependent on any other scenario
quick fail is nice approach, you might disable it for stable builds to check everything and keep it for work in progress scenarios to make quick itterations