Log spec code runtime errors

[hans2520]

This is probably more of a feature request, but it's observed that the console output doesn't seem to print anything related to the actual error when a runtime error is present in the test spec code.

With "LogOnError" setting, the successful console statements leading up to the error will be printed, then stop when the runtime error is encountered -- from the terminal perspective, it looks like nothing went wrong, of course it obviously did because otherwise no statements would have been logged at all.

It's obvious to see what the runtime error is when running in full Cypress browser, but still this would be nice for us since we routinely do dev in a non-GUI environment, so it can be an inconvenience to need to spin up the VNC session to see what's actually wrong...

Slightly tangential (and maybe the same root cause), but stack traces and details related to the error that normally appear in the Cypress browser also do not end up in terminal report. i.e. if you have an error in a custom function (not at test root), the terminal report will log a statement saying a function failed, but that's it -- no details on why / stack trace that appears in the full Cypress browser.

[archfz]

When there are syntax errors, doesn't cypress write these at the end out either way?

I am a little bit confused for two reasons:

• if you use webpack, you automatically cannot compile the file if you have syntax errors, and you get the output of webpack which tells you where the error is
• if you have a syntax error in the root of the test block you automatically won't even run any command thus nothing should be able to print with this plugin

Maybe wrong terms are used. Best would be if you give a minimal example spec, the current output and your expected out for it.

[hans2520]

Yes you're right, syntax error is the wrong type. Webpack blows up, I was too imprecise in my verbiage. I just tested with both a ReferenceError and TypeError, and each created the symptoms described. I guess it probably applies to the other runtime errors you can produce within the test spec code.

Simple example:

it("test"), () => {
  const a = b;
  a = 1;
}

[archfz]

As I said you should provide the current and expected output.

In the example above you are not running any cypress commands, so it either way wouldn't output anything. Even if you had some commands before that code, those commands would never get to run because of the queue nature of cypress, thus again no possible way to log anything with this example.

We could maybe use https://docs.cypress.io/api/cypress-api/catalog-of-events#Catching-Test-Failures , but this would include I believe both types of errors: commands failing or uncaught test exceptions.

[archfz]

But I am still struggling to understand the need, as cypress already either way outputs the last error, and in your case it would be the uncaught runtime exception.

[archfz]

Due to inactivity I am closing this. However feel free to provide any further clarification if you still think this is a valid requirement.