When running tests using `--runTestsByPath <some-path>`, the tests were
being run twice because jest-runner-vscode
[resolves test paths](0c98dc12ad/packages/jest-runner-vscode/src/runner.ts (L57-L66)),
while the original arguments were also still passed to Jest. So, the
arguments Jest would receive would look something like
`test/vscode-tests/no-workspace/databases/local-databases/locations.test.ts /Users/koesie10/github/vscode-codeql/extensions/ql-vscode/test/vscode-tests/no-workspace/databases/local-databases/locations.test.ts`
which would cause Jest to run the tests twice. This fixes this by
resolving the paths to their absolute paths, and then removing any
duplicates.
Instead of deleting the complete `_VSCODE_NODE_MODULES` object, we now
use a `Proxy` to intercept the `_isMockFunction` property. This is safer
and will not delete a global variable that VSCode expects to exist.
This fixes the tests on VSCode 1.74.0. The issue is as follows:
1. Jest wil try reset all mocks after each test, as it should.
2. When Jest does this, it will loop over all global variables and check
if they are mocks.
3. One of the global variables it checks is _VSCODE_NODE_MODULES, which
is a proxy object.
4. When Jest checks whether it is a proxy by getting _isMockFunction on
it, the `get` function on the proxy object will be called.
5. This will in turn call require, which will try to load
the non-existing `_isMockFunction` module. This throws the error we are
seeing.
By removing the `_VSCODE_NODE_MODULES` property from the global object
in the Jest environment, Jest will not try to reset it, and the tests
should work again.
See: 41bf230089/packages/jest-runtime/src/index.ts (L1173-L1186)
See: ed442a9e99/src/bootstrap-amd.js (L15)
This will update the `jest-runner-vscode` patch to retry tests that fail
due to no test result being returned from the test runner.
This will also add some retries to the `minimal-workspace` and
`no-workspace` tests to help with flakiness.
Multiple VSCode instances were being launched when a second instance of
VSCode was being spawned with the same user data directory. This is
probably because VSCode restores the windows from the previous session,
even when `-n`/`--new-window` is passed.
This fixes it by patching `jest-runner-vscode` to always create a new
temporary user data directory, rather than re-using the same one for
all test suites.
This will patch `jest-runner-vscode` to retry tests. This is a temporary
test to see if this will help with the flakiness of the CLI integration
tests.
The biggest problem with this is that it will launch multiple VSCode
instances on every retry:
- First try (not a retry): 1 instance
- Second try: 2 instances
- Third try: 3 instances
- etc.
I'm not sure why this is happening and can't really narrow it down to a
specific cause. Even if I change the `runVSCode` call for the retry by
a simple `cp.spawn` call, it still launches multiple instances.
Koen Vlaswinkel