luke-hill on main
add ruby 3.1 support bump rubocop from 1.7.0 to 1.24… downgrade ruby 2.5.9 to 2.5.8 and 4 more (compare)
olleolleolle on main
update changelog Merge pull request #528 from mg… (compare)
mgrunberg on main
add rails 7 to readme Merge pull request #527 from mg… (compare)
mgrunberg on main
add rails 7 support Three test… Update rubygems on ruby 2.5 Te… Merge branch 'main' into rails-7 and 3 more (compare)
binding.prybut fails when run as part of my Ruby step file. Any advice?
 pry(#<Cucumber::Rails::World>)> page.first('a', text: "edit") => #<Capybara::Node::Element tag="a" path="/html/body/div/div/div/div/div/form/div/p/div/div/div/div/div/table/tr/td/a">  pry(#<Cucumber::Rails::World>)> page.first('a', text: "edit").click => Obsolete #<Capybara::Node::Element>  pry(#<Cucumber::Rails::World>)>
binding.prythen 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.
sleep 5, does it work? Is the page not done moving around and it is working in
prybecause it has extra time before you start typing things at it?
sleepa 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.
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