Fix browser test suite #12117
Merged
Fix browser test suite #12117
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
update: I have worked-around the problem below by re-ordering this test's operations. I think I've found something that derails the
I will skip these two testcases for now - they will be accounted as "pending" in the testsuite results. |
marcdumais-work
force-pushed
the
fix-browser-tests
branch
11 times, most recently
from
03d09f0
to
02ef44e
Compare
marcdumais-work
force-pushed
the
fix-browser-tests
branch
6 times, most recently
from
e5bc00c
to
3e4b5c4
Compare
marcdumais-work
force-pushed
the
fix-browser-tests
branch
5 times, most recently
from
1238e3b
to
08bf3bc
Compare
marcdumais-work
force-pushed
the
fix-browser-tests
branch
3 times, most recently
from
2ff6ad1
to
15a32b4
Compare
Since they consistently fail, following a recent change that uncovered a deeper bug in the preferences. This commit can be reverted once we have a fix for #12153 Signed-off-by: Marc Dumais <marc.dumais@ericsson.com>
Opened editors referencing a deleted file have string (Deleted) after the file name. It used to be (deleted). This commit adapts to the modified case. Fixes #12081 Signed-off-by: Marc Dumais <marc.dumais@ericsson.com>
Testcases 'references-view.find'/'references-view.findImplementations' is triggering a couple of exceptions that result in error pop-ups in the app, that seem to intermitently derail the following test cases. It happens when opening the references view directly, but not when triggering the find references / find implementations, which in any case also open the view. In consequence, I have reorganized the order of operations to minimize issues: trigger the commands first, then "open" the already opened view to get a handle on it and be able to confirm that the content is what's expected. Observing the failure points, added a bit more strategic "robustness" to the following TypeScript tests: - editor.action.triggerSuggest - Can execute code actions - editor.action.quickFix Also added a delay in beforeEach and afterEach handlers, to give time for code action contributions to be updated when editors are closedand reopened. This helped with a few intermittent problems. Signed-off-by: Marc Dumais <marc.dumais@ericsson.com>
Add strategic delays to avoid a race condition that happens when files are closed and opened in quick succession. This testcase opens and closes a '.js' file many times very quickly. The specific file triggers the eslint and typescript-language-features plugins to register code action handlers, that rely on the open file's to be referenced in a structure maintained by the plugin system. Code actions are immediately triggered upon the file being re-opened, and I think previously registered handler do not always have enough time to be cleared, and end-up throwing when the file can't be found in the plugin system's internal structure (DocumentsExtImpl) I tried but was not able to reproduce the issue manually, openning the file from the explorer and closing it using shortcut shift-alt-w as quick as possible. note: included a review suggestion by paul-marechal Signed-off-by: Marc Dumais <marc.dumais@ericsson.com>
This one was tricky to find.
An exception would happen that failed the current test file, usually launch-preferences.spec.js,
only when running the full browser test suite. However, if that file was removed, the exception
would happen in another file, and another file...
Turns-out it's related to the vscode.json-language-features built-in extension and playing with
the package.json file.
It seems the problem is with the Language LinkProvider feature, and its usage by the
json-language-features extension. But I could not reproduce it outside of the test suite.
Here's what the exception looks-like:
root INFO 1) Launch Preferences
"before all" hook in "Launch Preferences":
Uncaught Error: Uncaught Error: There is no document for file:///home/<user>/theia/examples/browser/package.json
Error: There is no document for file:///home/<user>/theia/examples/browser/package.json
at LinkProviderAdapter.provideLinks (/home/<user>/theia/packages/plugin-ext/lib/plugin/languages/link-provider.js:31:35)
at /home/<user>/theia/packages/plugin-ext/lib/plugin/languages.js:332:97
at LanguagesExtImpl.withAdapter (/home/<user>/theia/packages/plugin-ext/lib/plugin/languages.js:123:20)
at LanguagesExtImpl.$provideDocumentLinks (/home/<user>/theia/packages/plugin-ext/lib/plugin/languages.js:332:21)
at /home/<user>/theia/packages/plugin-ext/lib/common/proxy-handler.js:91:71
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at async RpcProtocol.handleRequest (/home/<user>/theia/packages/core/lib/common/message-rpc/rpc-protocol.js:167:28) (http://127.0.0.1:3000/vendors-node_modules_theia_monaco-editor-core_esm_vs_base_common_severity_js-node_modules_the-68fc42.js:1785)
I went with a simple fix: have the keybindings tests use an alternative file instad of package.json.
Signed-off-by: Marc Dumais <marc.dumais@ericsson.com>
…meout
These test suites executes early, a the same time plugins are started. The default 2000ms
timeout would occasionally seemingly not be enough. Increasing it a bit.
e.g.:
2023-02-17T20:28:21.717Z root INFO 1 failing
2023-02-17T20:28:21.719Z root INFO 1) animationFrame
should resolve after the given number of frames:
Error: Timeout of 2000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves.
2023-02-20T14:54:45.051Z root INFO 1 failing
2023-02-20T14:54:45.051Z root INFO 1) Find and Replace
"after each" hook for "Replace in the active explorer with the current editor":
Error: Timeout of 2000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves.
Signed-off-by: Marc Dumais <marc.dumais@ericsson.com>
Re-use puppeteer's empty Chrome tab: Puppeteer at some point started to open the Chrome browser with an empty tab by default. Then, when we create a new page for our tests, a new tab would be added. At least When running the tests with UI (option --test-inspect), sometimes the empty tab would be selected and apparently cause many tests to fail. It's possible that this also sometimes happened in headless mode. To avoid this, now re-use the empty tab instead of creating a new one. Make sure the Theia test app has focus and clear local browser storage: When launching in non-headless mode (with a UI and dev-tools open), it looks-like the dev-tools have focus, which interferes with some tests that query the UI, expecting our app to be in focus. Simply clicking on the app before starting the tests fixes it. Also clear the local browser storage, to possibly avoid starting the app with some state from the previous run. This could help when running the tests locally, since CI should in theory always start with a clean environment. Disable retry for failed tests in mocha config: It only seems to make things worse. Allow vieport to take available space instead of default 800x600: This gives much more space for the Theia app, specially when running in non-headless mode, where the editors can have very little real-estate when views on the sides are open. Delay exit after test finish: When running the suite in headless mode, it exits as soon as the mocha tests are done executing. In some cases, where there are lots of errors to report[1], the final report did not have the chance to be printed-out, and so we were left wondering about the details of what caused the failures. [1]: basically the final pass/not pass/skip count as well as details about the failed tests. note: includes a review suggestion by paul-marechal. Signed-off-by: Marc Dumais <marc.dumais@ericsson.com>
marcdumais-work
force-pushed
the
fix-browser-tests
branch
from
15a32b4
to
6672a02
Compare
vince-fugnitto
added
ci
|
@tsmaeder FYI |
|
@marcdumais-work awesome. If we have confidence that the will only report true breakage now, we should tell the community that they need to start paying attention to failures again. I'm pretty sure everyone is just going "meh!" right now. |
vince-fugnitto
approved these changes
Feb 21, 2023
There was a problem hiding this comment.
LGTM 👍 The state of the api integration tests are much better with the pull-request and it is always possible to improve it further as needed:
- CI passes successfully
- running the tests locally pass (ran 3 times without failure)
- running the tests on my fork pass (ran 3 times without failure)
|
CI is failing on master after merging?? https://github.com/eclipse-theia/theia/actions/runs/4244786034/jobs/7379398368 |
Hummm. I don't think I have seen this specific error before :( I will try running locally to see if I can reproduce. |
1 task
This was referenced Mar 22, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #12081
Signed-off-by: Marc Dumais marc.dumais@ericsson.com
What it does
The browser test suite has been failing a lot for a while. This is an attempt to make it more solid.
While working on this I noticed that running the suite locally with a UI (using the
--test-inspectCLI option) would work worse than headless. I have made some adjustments to fix this, even though it may not really affect CI, since it's helpful to be able to debug the suite locally.I found that several of the test suites/files were failing, at least one always, others intermittently. I was not always able to go to the bottom of the failures but in some cases found work-arounds that seem to help.
Finally, the
launch preferencestest suite has issues since a recent improvement that revealed some underlying problems - I have disabled it until these issues can be fixed. See #12153 for more details.See commit messages for more info about the changes.
How to test
The browser tests should pass!
To run locally:
yarn browser testRun with UI:
yarn browser test:debugReview checklist
Reminder for reviewers