Conversation
hi-rai
requested review from
AndrianBdn,
ramilamparo,
satvik007 and
sirkostya009
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the QA Sphere CLI's reporting capabilities by enabling the upload of run-level failure logs. Previously, only individual test case results were captured. Now, the system can identify and report broader issues, such as setup or teardown failures, that impact an entire test run rather than a specific test. This provides a more comprehensive view of test execution health by ensuring that critical, non-test-case-specific errors are not overlooked. Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds support for uploading run-level failure logs from JUnit XML and Playwright JSON reports. The changes are comprehensive, including updates to the API client, parsers, upload logic, tests, and documentation. The implementation correctly identifies suite-level errors and handles them separately from test case results. I've found one area for improvement in the JUnit XML parser to avoid duplicate headers in the generated failure log, which would improve the readability of the output.
| for (const suite of validated.testsuites.testsuite) { | ||
| const suiteName = suite.$?.name ?? '' | ||
|
|
||
| // Extract suite-level system-err into runFailureLogParts | ||
| for (const err of suite['system-err'] ?? []) { | ||
| const content = (typeof err === 'string' ? err : (err._ ?? '')).trim() | ||
| if (content) { | ||
| if (suiteName) runFailureLogParts.push(`<h4>${escapeHtml(suiteName)}</h4>`) | ||
| runFailureLogParts.push(`<pre><code>${escapeHtml(content)}</code></pre>`) | ||
| } | ||
| } | ||
|
|
||
| for (const tcase of suite.testcase ?? []) { | ||
| const tcaseName = tcase.$.name ?? '' | ||
|
|
||
| // Empty-name testcases with error/failure can be synthetic entries from | ||
| // setup/teardown failures (e.g., Maven Surefire). Extract into runFailureLogParts | ||
| // and exclude from testCaseResults. | ||
| if (!tcaseName && (tcase.error || tcase.failure)) { | ||
| const elements = tcase.error ?? tcase.failure ?? [] | ||
| for (const element of elements) { | ||
| const content = (typeof element === 'string' ? element : (element._ ?? '')).trim() | ||
| if (content) { | ||
| if (suiteName) runFailureLogParts.push(`<h4>${escapeHtml(suiteName)}</h4>`) | ||
| runFailureLogParts.push(`<pre><code>${escapeHtml(content)}</code></pre>`) | ||
| } | ||
| } | ||
| continue | ||
| } |
There was a problem hiding this comment.
The current logic for collecting run-level failure logs may produce duplicate suite name headers (e.g., <h4>MySuite</h4>) if a test suite contains both a suite-level <system-err> and an empty-name <testcase> with an error. This can make the final log appear redundant.
To improve this, I suggest refactoring to collect all run-level errors for a given suite into a temporary array first. After processing the entire suite, you can then add the suite header once (if needed), followed by all the collected error parts. This ensures each suite name is displayed only once as a header for all its associated run-level errors.
1 participant
This fixes https://github.com/Hypersequent/tms-issues/issues/2340