This does not seem intuitive, as the new user defined in the step may have different field data than the prior, field data that could be important for the test.
Proposed resolution
Eliminate the if (!$this->loggedInWithRole($role)) { check and just get into creating the new user in Drupal\DrupalExtension\Context\DrupalContext::assertAuthenticatedByRoleWithGivenFields(), simliar to how things are done in Drupal\DrupalExtension\Context\DrupalContext::assertLoggedInWithPermissions(). Essentially, always do what the step asks for regardless of who is currently logged in.
An alternate resolution might be to check that both the new user's roles and field data match the currently-logged-in user before deciding to skip user creation. This would be a more complex way to resolve the issue, but would maintain the optimization of re-using the existing user if what's asked for is the same. However, I doubt the situation of old and new user matching on both roles and field data would be a common one (why create the step in the scenario at all?), and so I lean toward the simpler resolution above.
This does not seem intuitive, as the new user defined in the step may have different field data than the prior, field data that could be important for the test.
Proposed resolution
Eliminate the
if (!$this->loggedInWithRole($role)) {check and just get into creating the new user inDrupal\DrupalExtension\Context\DrupalContext::assertAuthenticatedByRoleWithGivenFields(), simliar to how things are done inDrupal\DrupalExtension\Context\DrupalContext::assertLoggedInWithPermissions(). Essentially, always do what the step asks for regardless of who is currently logged in.An alternate resolution might be to check that both the new user's roles and field data match the currently-logged-in user before deciding to skip user creation. This would be a more complex way to resolve the issue, but would maintain the optimization of re-using the existing user if what's asked for is the same. However, I doubt the situation of old and new user matching on both roles and field data would be a common one (why create the step in the scenario at all?), and so I lean toward the simpler resolution above.