Handle a multi-line desc in R test explorer (on Windows)#14336
Conversation
Also some refactoring of the test explorer testing utilities
PETE's assessment 🧪Verdict: 🟢 Adequate -- the new What changed
Tests in this PR
Existing coverageThe Suggested additionsNone for coverage. One correctness caveat worth a human look before merge (outside the coverage verdict): the unit test asserts newline escaping -- e.g. PETE (Positron Extreme Test Experiment) - LLM-based test-coverage advisor, in pilot. Triggers on PR open and on |
|
E2E Tests 🚀 |
|
I saw the expected test failures:
|
Otherwise, the attempt to focus it is a no-op and later expectations fail for the wrong reason.
desc in R test explorer (on Windows)
…results This appears to be happening at the testthat level.
|
The chromium failure seems to be that the test explorer was not focused. So that failure is not really about what we're addressing. Fixing that. The windows failure seems to be continued struggle to get the test item label in the explorer to match what testthat emits, on Windows, in the presence of a multi-line |
| // The view container's activity-bar icon appears once test discovery has | ||
| // populated it; wait for that before focusing, or the command no-ops. | ||
| await this.code.driver.currentPage.locator(TEST_EXPLORER_ICON).waitFor({ state: 'visible' }); | ||
| await this.quickaccess.runCommand('workbench.view.testing.focus'); |
There was a problem hiding this comment.
Switching to a less janky method of focusing the test explorer, while we're here.
| // Tests share one app instance; reset to a known state. | ||
| await testExplorer.collapseAllTests(); | ||
| await testExplorer.clearAllTestResults(); |
There was a problem hiding this comment.
Beneficial once we go from 1 e2e to test to 2 and, before long, >2.
| import { parseTestsFromFile } from '../testing/parser'; | ||
| import { ItemType, TestingTools } from '../testing/util-testing'; | ||
|
|
||
| suite('parseTestsFromFile', () => { |
There was a problem hiding this comment.
These feels a bit over the top for this one thing, but I know this whole effort will create more integration tests, so might as well get started now.
|
I believe the Windows CI failure has nothing to do with this PR (and, indeed, Windows has passed along the way here), but so far my latest retries keep hitting the same snag (difficulty installing one of the node dependencies). |
juliasilge
left a comment
There was a problem hiding this comment.
This is working great for me and looks good!
Before you merge, can you please update the PR summary using either the /positron-pr-helper skill or the template in https://github.com/posit-dev/positron/blob/main/.github/pull_request_template.md? It is still pretty necessary for us to have the release notes in each PR.
|
AFAICT the CI failures continue to have nothing to do with the content of this PR. |
juliasilge
left a comment
There was a problem hiding this comment.
Thank you! 🙌
Are these tests failing on main? Are they known to be flaky?
|
Yeah I feel like this PR runs through a variety of test flakes. Different ones from run to run. Here is co-pilot's analysis of the most recent failures, which match my impression of this having nothing to do with the content of the PR.
PR scope check (PR #14336)
So the failure evidence points to external/dependent areas (dependency fetch 403, segfault, reticulate flake), not your PR’s core content. |
Fixes #10133
The challenge is to run a single test from the test explorer when (1) the test item has multiple lines (strange, but not forbidden) and (2) the OS is Windows.
The fix ended up having 2 parts:
\n(vs., say,\r\n). This matches what testthat does. This parser change affects our test item labels.\nto guarantee that it is treated as part of thedesctext in the command executed to run an individual test, as opposed to truncating the command prematurely. This "just works" on linux and macOS without explicit escaping, but apparently we have to be more defensive on Windows.Together, these changes ensure that the test explorer can (1) successfully run an individual item and that (2) we can match up test results emitted by testthat with test item labels in our tree.
I added a unit test, an integration/extension test, and an e2e test. Bewtween CI and locally, I've seen all of them fail before the fixes and succeed after the fixes.
Snippet from e2e-windows:
Release Notes
New Features
Bug Fixes
@:win @:test-explorer @:web