-
-
Notifications
You must be signed in to change notification settings - Fork 52
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
Missing additionnal context from GoogleTest failures #436
Comments
You seed the problem correctly, how could this extension know that the next line is related to the previous error. But this might special in the sense that after a failure we just expect the test to finish. |
Maybe everything before the Google Test has an option for structured output:
Not sure since when, and it only outputs to a file, but it could be an alternative. |
If I remember correctly the problem with that it is not continuous but just spits out the result at once at the end so cannot be parsed during running the exec. They might changed it since. idk. Parsing until the end would for for "assert" but not for "except". I don't think it's possible to tell which one is happening. |
There's a Though that doesn't help much with output capturing; for that probably still the best way is to report everything between the [RUN] and [OK]/[FAILED] markers for the test as a whole.
At least for output solely generated by the assertions themselves, anything between one failure report and the next is all related to the former failure. Unfortunately this gets muddied if the test also generates additional output to stdout/stderr directly, as that usually precedes the failure they relate to instead, and as you said there isn't a good way to tell purely from stdout when output of the previous failure ends and manual stdout for the next failure begins. Parsing the XML output does give you only the specific failure messages; perhaps some combination of all three would be the ideal? (streaming output for live progress, XML parsing for failure overlays, stdout for the Test Results -- perhaps comparing against the XML messages to decide which failure each stdout line "belongs" to?) The XML output is generated in addition to regular stdout, so they can both be used together, and until streaming output is more widely supported you could continue to guess progress from stdout until the tests finish and the XML is available. |
Fixed in v4.12.1.This issue was mentioned in CHANGELOG.md under a released entry so it is assumed to be fixed. |
Checklist
I understand that you have privacy concerns and I expect you to understand that this extension is developed for free.
Thanks.
Describe the bug
Using the extension, additionnal context passed to GoogleTest is lost in the in-line report.
It is shown in test results:
And when running the test executable directly:
When using a macro that already prints some more information, I can get it to show by adding at least two spaces before:
This does not work with the
FAIL()
macro, however many spaces I add before.This is probably an improvement to make to the output parser that determines what is to be shown and what is not.
Another case is with exceptions.
With this test, no overlay can even be shown:
Information is displayed in the test results panel:
Ideally, this stuff should be displayed to help debug failed tests. It is currently possible to look for it in the test results panel, but the overlay is easier to use, and therefore it would be nice to have it there.
To Reproduce
libgtest-dev
installed fromapt
:a.out
.Desktop
apt
) and 1.14.0 (vcpkg
)(The reproductible example above was tested on the host. My own project is more complex, but gives the same results. This one runs in Docker).
Regression bug?
No, tried 4.1.0 and it did not work. Before that, the overlay did not work (4.0.0) or the test explorer did not show anything < 4.0.0).
**Log** (optional but recommended)
The log was taken in a fresh Ubuntu 20.04 Docker container, using the exemple above.
The text was updated successfully, but these errors were encountered: