Skip to content
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

willBeRetried is not under result anymore after "@cucumber/cucumber": "^8.0.0", #2010

Closed
Huseyinaltas1 opened this issue Apr 25, 2022 · 7 comments
Labels
🐛 bug Defect / Bug ✅ accepted The core team has agreed that it is a good idea to fix this

Comments

@Huseyinaltas1
Copy link

Huseyinaltas1 commented Apr 25, 2022

"willBeRetried" was a property of "result" before I upgraded to "@cucumber/cucumber": "^8.0.0".
I see now it is "undefined" for below hook. I did not find willBeRetried in any other ITestCaseHookParameter Interface. Thank you in advance.

After(async function (scenario) {
console.log(scenario.result.willBeRetried)
}

#######

I was expecting to make sure scenario will be retired or not.
Node: 16.14.2
npm:8.5.0
"dependencies": {
"@cucumber/cucumber": "^8.0.0",
"@ericblade/quagga2": "^1.4.2",
"axios": "^0.26.0",
"dotenv-flow": "^3.2.0",
"googleapis": "^88.2.0",
"pixelmatch": "^5.2.1",
"puppeteer": "^13.5.0",
"puppeteer-har": "^1.1.2",
"sharp": "^0.29.3",
"tesseract.js": "^2.1.5"
}

#######

When you try this with above dependencies, It is reproduced.

After(async function (scenario) {
console.log(scenario.result.willBeRetried)
}
Output: undefined

@aurelien-reeves
Copy link
Contributor

Hello, and thanks for reporting this.

There have been some changes with the willBeRetried property.

We have missed to document that change 😓

The willBeRetried info is now part of the messages and can be found in the testCaseFinished one.

May I ask: what is your need? What are you trying to achieve? Is it for reporting purpose or for something else?

@davidjgoss
Copy link
Contributor

Yeah willBeRetried was kind of misplaced on the test step result message hence the move.

This feels somewhat related to #1851 - we expose the messages to the hooks but these can change and aren't very ergonomic to use on their own without the associated querying libraries.

May I ask: what is your need? What are you trying to achieve? Is it for reporting purpose or for something else?

Definitely interested in this too! I see no issue with adding willBeRetried to that hook parameter, but would be good to really understand the need.

@davidjgoss davidjgoss added 🐛 bug Defect / Bug ✅ accepted The core team has agreed that it is a good idea to fix this labels Apr 26, 2022
@Huseyinaltas1
Copy link
Author

Huseyinaltas1 commented Apr 26, 2022

Thank you @aurelien-reeves and @davidjgoss for response.

"The willBeRetried info is now part of the messages and can be found in the testCaseFinished one."

I don't see any messages interface there unfortunately. I checked types.d.ts and there is no messages parameter either. I see only gherkinDocument, pickle, result, testCaseStartedId.

`
export interface ITestCaseHookParameter {

gherkinDocument: messages.GherkinDocument;

pickle: messages.Pickle;

result?: messages.TestStepResult;

testCaseStartedId: string;

}
export interface ITestStepHookParameter {

gherkinDocument: messages.GherkinDocument;

pickle: messages.Pickle;

pickleStep: messages.PickleStep;

result: messages.TestStepResult;

testCaseStartedId: string;

testStepId: string;

}
`

May I ask: what is your need? What are you trying to achieve? Is it for reporting purpose or for something else?

I save screenshot of a e-commerce receipt barcode with scenario name but if it is failed and will be run secondly I am adding '-2nd' string as Suffix end of this screenshot name. Like:
scenario.result.willBeRetried == true ? (scenarioScope.secondRun = '-2nd') : (scenarioScope.secondRun = '');
this.scenarioId = step.pickle.id + '' + secondRun;

@aurelien-reeves
Copy link
Contributor

Disclaimer: I did not tried what I will suggest next 😅

What about keeping in the world the testcase Id, and the number of time it has been run, and relying on that info instead?

@Huseyinaltas1
Copy link
Author

Actually I have another solution for that for now. I just wondered if it was a defect and I wanted to help cucumber family. 😅

@aurelien-reeves
Copy link
Contributor

That is nice actually, thank you!

So, no, this is not a defect. This is an impact of something else done on purpose

So, if you find a workaround, that is great. Would you agree to close the issue? We could still easily reopen it if someone else report that "issue" and requires a more concrete fix!?

@Huseyinaltas1
Copy link
Author

I am closing. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐛 bug Defect / Bug ✅ accepted The core team has agreed that it is a good idea to fix this
Projects
None yet
Development

No branches or pull requests

3 participants