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.
This adds debugging support to jest-runner for the integration tests
when they are run from the `out` directory. Unfortunately, this removes
the ability to debug the non-integration tests, such as the pure tests.
Instead of running the integration tests from the `out` directory, this
will run the integration tests from the `src` directory using `ts-jest`.
Unfortunately, we are not able to use TypeScript files for the
`jest-runner-vscode` configuration since `cosmiconfig` (the package that
handles the configuration loading for `jest-runner-vscode`) doesn't
support loading TypeScript files by default.
Since we are launching a completely different process for the extension
tests than the process that is launched by VSCode, we need to add some
special handling for the debugging.
This will let the extension host/VSCode expose a debugging port, which
VSCode will then connect to. This is "less desirable than letting the
bootloader do its thing", but a packaged VSCode application does not
allow using the bootloader (`NODE_OPTIONS`=`--require=...`). Therefore,
we have to fallback to this option.
See: 47c60558ec/src/configuration.ts (L405-L411)
Apparently, we're not importing the same `config` file as is used by the
actual extension, so mocking methods in this file does not do anything.
However, we can mock the `vscode` module, so we can use this for
returning different values in the configuration.
We also need to mock the authentication session since we don't have one.
This will ensure all mocks are restored after every test. This required
a significant amount of changes in the tests since `jest.spyOn` now
needs to be called in `beforeEach`, rather than in the `describe` block.
There were some things that were breaking due to version checks. Since
we aren't testing on these CLI versions (2.7.2 and 2.7.4 or older)
anymore, we can remove these checks and simplify the tests.
For `to.contain`, `jest-codemods` seems to have converted these to be
`expect.arrayContaining`, even for strings. This will make the correct
change for strings.
Jest does not support skipping tests when the test has already started
(which could also be in a before hook), so we need to manually return
from the tests when the CLI version does not support a tested feature.
Instead of calling `fail`, we can just let the error be caught by Jest,
which will automatically fail the tests. For other instances where we're
calling `fail` in case an error was not thrown, we will instead use
`.rejects.toThrow`.
This is a first pass on converting the cli-integration tests to Jest. It
uses a custom Jest runner (based on the jest-runner-vscode) to install
required extensions. It will also necessary to move some code for
installating the CLI to ensure it was possible to install the CLI from
outside VSCode.
Most of the conversion has been done by `npx jest-codemods`, but all
migration of Sinon has been done manually.
The filter and sort tests were located inside the React tests since they
were already using Jest. Now that the pure tests have been switched to
Jest, these tests can finally be moved to the "normal" pure tests.
The timeouts need to be set either on a per-file basis, or per test by
using the parameter in `it`. Since we have both Mocha and Jest types, we
need to declare in the test file which one we're using.
This migrates all no-workspace VSCode integration tests to Jest by
running `npx jest-codemods`, followed by manual fixes (mostly for Sinon
and Proxyquire).
