-
-
Notifications
You must be signed in to change notification settings - Fork 150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
After hook and Before hooks are not running if a failure occrurs #824
Comments
Related issue: |
This is by design and matches behavior found in Cucumber. If you want |
Okay, thanks for the quick reply. |
Hello, I believe we need to reopen this. The behavior of an
While that above is for Cucumber-Java, the same behavior works for Cucumber-JS where a tagged hook will still run post-scenario. I can reproduce this behavior if needed. |
Re-opening, as this does in fact seem to the behavior exhibited by Cucumber, despite what I was thinking earlier. This is likely a pretty substantial change and I don't have the ability to look into it right now. Anyone feeling particularly compelled can take a shot at it meanwhile. |
Messages are no longer lingering in the runtime, but passed along to the backend using tasks immediately. This is a prerequisite for the following issues: - 810 [1] - 824 [2] - 944 [3] This is not to say that these will be fixed shortly or even at all, but at least now it will be remotely possible. Furthermore, this removes any doubt regarding whether reports work in interactive mode. The experimental flag simply turns out to be too broken [4-5]. Interactive mode is now detected and reports turned off. Lastly, detecting interactive mode is a somewhat broken feature [6]. The workaround (using `isTextTerminal`) is only available in Cypress v10 and beyond. Thus is Cypress v9 now unsupported. [1] #810 [2] #824 [3] #944 [4] cypress-io/cypress#18955 [5] cypress-io/cypress#26634 [6] cypress-io/cypress#20789
Messages are no longer lingering in the runtime, but passed along to the backend using tasks immediately. This is a prerequisite for the following issues: - 810 [1] - 824 [2] - 944 [3] This is not to say that these will be fixed shortly or even at all, but at least now it will be remotely possible. Furthermore, this removes any doubt regarding whether reports work in interactive mode. The experimental flag simply turns out to be too broken [4-5]. Interactive mode is now detected and reports turned off. Lastly, detecting interactive mode is a somewhat broken feature [6]. The workaround (using `isTextTerminal`) is only available in Cypress v10 and beyond. Thus is Cypress v9 now unsupported. [1] #810 [2] #824 [3] #944 [4] cypress-io/cypress#18955 [5] cypress-io/cypress#26634 [6] cypress-io/cypress#20789
Messages are no longer lingering in the runtime, but passed along to the backend using tasks immediately. This is a prerequisite for the following issues: - 810 [1] - 824 [2] - 944 [3] This is not to say that these will be fixed shortly or even at all, but at least now it will be remotely possible. Furthermore, this removes any doubt regarding whether reports work in interactive mode. The experimental flag simply turns out to be too broken [4-5]. Interactive mode is now detected and reports turned off. Lastly, detecting interactive mode is a somewhat broken feature [6]. The workaround (using `isTextTerminal`) is only available in Cypress v10 and beyond. Thus is Cypress v9 now unsupported. [1] #810 [2] #824 [3] #944 [4] cypress-io/cypress#18955 [5] cypress-io/cypress#26634 [6] cypress-io/cypress#20789
Messages are no longer lingering in the runtime, but passed along to the backend using tasks immediately. This is a prerequisite for the following issues: - 810 [1] - 824 [2] - 944 [3] This is not to say that these will be fixed shortly or even at all, but at least now it will be remotely possible. Furthermore, this removes any doubt regarding whether reports work in interactive mode. The experimental flag simply turns out to be too broken [4-5]. Interactive mode is now detected and reports turned off. Lastly, detecting interactive mode is a somewhat broken feature [6]. The workaround (using `isTextTerminal`) is only available in Cypress v10 and beyond. Thus is Cypress v9 now unsupported. [1] #810 [2] #824 [3] #944 [4] cypress-io/cypress#18955 [5] cypress-io/cypress#26634 [6] cypress-io/cypress#20789
As per now, the plugin will register a single In order to ensure that However, errors ocurring in Thus, if For this reason, I believe it is unlikely that this issue will be fixed. |
Hey, so I am coming back to this as I had a few questions. For Cucumber, the For a failure to occur, I believe this means within the test steps and not within the hooks. A failure in the hooks is understandable, but it does not make sense that an Instead, the function within an Skipping an I'd like to look into this if you can point me in the right direction -- I believe something can be done. |
The following tests, test output in case of failures in
This is the behavior I believe you will have some trouble retaining when moving In any case, the code you want to look into resides in
The former is run in the browser and it's there you will find the internal |
FYI, you can use |
Edit: I reread that and then looked at the code -- I see what you mean. Why are Cucumber hooks ran separately from the Mocha hooks? If //This is essentially the same
After({tags: "@tag1"}, function() {
console.log('Hook executed');
})
//as this
afterEach(function(){
if(doesFeatureMatch("@tag1")){
console.log('Hook executed');
}
}); would it make sense that all Cucumber hooks are instead just a proxy for Mocha hooks? Like, creating an function After(tags, fn) {
return afterEach(function()) {
if(featureDoesMatch(tags){
fn()
}
}
} |
The problem with proxying |
Darn, that's tough. Would the same true if an |
That would skip the rest of the spec (test file), yes. This is simply just how Cypress works, I have no control nor influence over this. |
I understand -- just needed clarity. Thanks for updating; I think we should leave this issue open in the case that Cypress itself is updated to allow for better try/catch logic around hooks. |
Current behavior
The Before and After hooks will only run when tests pass.
Desired behavior
We want to be able to use the cucumber style After hook to run some test cleanup, even when tests fail. But currently the After hook will only run when the test passes.
Using the cypress afterEach hook is an option but it would be nice to use the cucumber After hook as it supports @tags
Test code to reproduce
Here is a link to an older test feature file from the cypress repo which illustrates the issue. The scenarios that illustrate this problem are commented out as they cause steps to fail, (Scenario: With Untagged After having test errors in steps part 1 & 2). The steps file only needed a minor tweak to pull { Given, Then, After, Before } from the right place.
https://github.com/badeball/cypress-cucumber-preprocessor/blob/77dbacb65741d559ae0eedd461f02970249f75d8/cypress/integration/BeforeAndAfterSteps.feature
Versions
Checklist
cypress-cucumber-preprocessor@4.3.1
(package name has changed and it is no longer the most recent version, see #689).The text was updated successfully, but these errors were encountered: