In our test suite we reset the database between scenario's to ensure test isolation, we also do this because for some upgrade paths we require a specifically prepared database.
However in a feature file that has:
Scenario: One
Given I am logged in as a user with the authenticated role
And I am on "/user/2/edit"
Scenario: Two
Given I am logged in as a user with the authenticated role
And I am on "/user/2/edit"
Then Scenario "Two" will fail on the "/user/2/edit" page because the user doesn't exist. Even when we reset the session, Mink doesn't throw away the page. So the logic in DrupalAuthenticationManager::loggedIn will see a started session and the previous (logged in) page and assume that the user is still logged in. However, the user will no longer exist in the database so when actually visiting a page that requires authentication this will now fail.
I would expect the DrupalExtension to just assume people are logged out when a new scenario is started. I also don't see an easy way to make it do this without an internal change to the extension.
In our test suite we reset the database between scenario's to ensure test isolation, we also do this because for some upgrade paths we require a specifically prepared database.
However in a feature file that has:
Then Scenario "Two" will fail on the "/user/2/edit" page because the user doesn't exist. Even when we reset the session, Mink doesn't throw away the page. So the logic in
DrupalAuthenticationManager::loggedInwill see a started session and the previous (logged in) page and assume that the user is still logged in. However, the user will no longer exist in the database so when actually visiting a page that requires authentication this will now fail.I would expect the DrupalExtension to just assume people are logged out when a new scenario is started. I also don't see an easy way to make it do this without an internal change to the extension.