-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Broken error rendering for custom Mocha reporters #6924
Comments
I'm getting an error throwing We did make changes to the construction of error messages in 4.3.0 in #3762 |
@jennifer-shehane My apologies for the mistake in the code. Here it is: function Reporter(runner) {
runner.on("fail", (test, error) => {
console.log(error);
});
}
module.exports = Reporter;
I understand that. I think you’ll find a regression between 4.2.0 and 4.3.0 though. :) |
This code is identical to the code pasted before. Is this supposed to be placed in the |
@jennifer-shehane Yes, I update my initial post with the fix so you can try again. It was missing the Allow me to give you all code snippets with their location again: // cypress.json
{ "baseUrl": "https://example.com" } // cypress/integration/examples/index.js
describe("Test", () => {
it("visit", () => cy.visit("/dgfkdgkj"))
}) // reporter.js
function Reporter(runner) {
runner.on("fail", (test, error) => {
console.log(error);
});
}
module.exports = Reporter; |
I'll look into this as part of #3930. |
I ran this with
The only difference is the message doesn't include
In this example, at least, the original error message is only That all said, it's clear this is a pared-down example for reproduction's sake, which I appreciate, but I'm not sure it demonstrates an actual issue. @hugogiraudel, if you could provide an example of an actual custom reporter that's behavior has been broken between |
Hello Chris and thank you for having a look. I’ll check next week again. :) |
Hello Chris. I’m finally coming back to this. My understanding is that it makes a big difference, because what you receive in 4.2.0 is an object — correct me if I’m wrong. That means you can read its keys, its values, and so on. In 4.3.0 however, the received |
You still receive an object with The difference is that Which reporter did you use that prompted this issue? Being able to reproduce the issue will enable me to debug it. |
Interesting, thank you for coming back to me so quick and explaining. I can reproduce the issue with the code samples I gave in my original comment. I’m a little puzzled why I see such differences between the 2 versions. |
Okay, I was able to reproduce this in a way that highlights the issue. Printing only the message shows a starker difference between // reporter.js
function Reporter(runner) {
runner.on("fail", (test, error) => {
console.log(error.message);
});
}
module.exports = Reporter; In
In
I'll look into how we can address this. |
Ah right, thank you for pinpointing the problem! So maybe, it’s related to the code snippets I outlined in my original post. That would lovely to have this addressed as logs are pretty polluted right now unfortunately. |
The code for this is done in cypress-io/cypress#3930, but has yet to be released. |
Released in This comment thread has been locked. If you are still experiencing this issue after upgrading to |
Current behavior:
I believe version 4.3.0 broke the error output with customer reporters. I think it might be coming from one of these snippets (L140 for the 1st, L111 for the 2nd):
cypress/packages/driver/src/cypress/error_utils.js
Lines 139 to 143 in 36866da
cypress/packages/server/lib/reporter.coffee
Lines 103 to 119 in 689bef0
On a simple test that visits a page that doesn’t exist (HTTP 404), the output looks like this now:
Text version:
Note the weird:
Desired behavior:
The main problem with this is that it doesn’t seem to be possible to get the original error message anymore. So a custom reporter is now stuck with Cypress’ hack without the ability to use the actual error message that was thrown.
My assumption is that this patching/String serialisation (L111) is happening too early. The given input is not a string, it seems to be JavaScript intended to compose a string through concatenation. Not sure. Doing a
typeof
onerror.message
also yieldsobject
instead ofstring
which is a problem as well.Test code to reproduce
Consider the following setup:
Versions
4.3.0.
The text was updated successfully, but these errors were encountered: