Microsoft/vscode
1
0
Fork 0
mirror of https://github.com/microsoft/vscode.git synced 2025-12-24 20:26:08 +00:00
Code Issues Packages Projects Releases Wiki Activity

web tests - mention how to enable playwright logging

Browse Source
This commit is contained in:
Benjamin Pasero
2021-08-26 10:34:17 +02:00
parent 514697c865
commit cdde5bedbf
3 changed files with 17 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
test/integration/browser/README.md
View File

@@ -4,23 +4,25 @@
Make sure to run the following commands to compile and install dependencies:
yarn --cwd test/integration/browser
yarn --cwd test/integration/browser compile
yarn --cwd test/integration/browser
yarn --cwd test/integration/browser compile
## Run (inside Electron)
scripts/test-integration.[sh|bat]
scripts/test-integration.[sh|bat]
All integration tests run in an Electron instance. You can specify to run the tests against a real build by setting the environment variables `INTEGRATION_TEST_ELECTRON_PATH` and `VSCODE_REMOTE_SERVER_PATH` (if you want to include remote tests).
## Run (inside browser)
resources/server/test/test-web-integration.[sh|bat] --browser [chromium|webkit] [--debug]
resources/server/test/test-web-integration.[sh|bat] --browser [chromium|webkit] [--debug]
All integration tests run in a browser instance as specified by the command line arguments.
Add the `--debug` flag to see a browser window with the tests running.
**Note**: you can enable verbose logging of playwright library by setting a `DEBUG` environment variable before running the tests (https://playwright.dev/docs/debug#verbose-api-logs)
## Debug
All integration tests can be run and debugged from within VSCode (both Electron and Web) simply by selecting the related launch configuration and running them.

4
test/smoke/README.md
View File

@@ -63,6 +63,8 @@ xattr -d com.apple.quarantine <path to server with web folder zip>
- `-f PATTERN` (alias `-g PATTERN`) filters the tests to be run. You can also use pretty much any mocha argument;
- `--screenshots SCREENSHOT_DIR` captures screenshots when tests fail.
**Note**: you can enable verbose logging of playwright library by setting a `DEBUG` environment variable before running the tests (https://playwright.dev/docs/debug#verbose-api-logs)
### Develop
```bash
@@ -80,7 +82,7 @@ On Windows, check for the folder `C:\Users\<username>\AppData\Local\Temp\t`. If
- Beware of workbench **state**. The tests within a single suite will share the same state.
- Beware of **singletons**. This evil can, and will, manifest itself under the form of FS paths, TCP ports, IPC handles. Whenever writing a test, or setting up more smoke test architecture, make sure it can run simultaneously with any other tests and even itself. All test suites should be able to run many times in parallel.
- Beware of **singletons**. This evil can, and will, manifest itself under the form of FS paths, TCP ports, IPC handles. Whenever writing a test, or setting up more smoke test architecture, make sure it can run simultaneously with any other tests and even itself. All test suites should be able to run many times in parallel.
- Beware of **focus**. **Never** depend on DOM elements having focus using `.focused` classes or `:focus` pseudo-classes, since they will lose that state as soon as another window appears on top of the running VS Code window. A safe approach which avoids this problem is to use the `waitForActiveElement` API. Many tests use this whenever they need to wait for a specific element to _have focus_.

15
test/unit/README.md
View File

@@ -2,7 +2,7 @@
## Run (inside Electron)
./scripts/test.[sh|bat]
./scripts/test.[sh|bat]
All unit tests are run inside a electron-browser environment which access to DOM and Nodejs api. This is the closest to the environment in which VS Code itself ships. Notes:
@@ -14,19 +14,20 @@ For instance, `./scripts/test.sh --debug --glob **/extHost*.test.js` runs all te
## Run (inside browser)
yarn test-browser --browser webkit --browser chromium
yarn test-browser --browser webkit --browser chromium
Unit tests from layers `common` and `browser` are run inside `chromium`, `webkit`, and (soon’ish) `firefox` (using playwright). This complements our electron-based unit test runner and adds more coverage of supported platforms. Notes:
- these tests are part of the continuous build, that means you might have test failures that only happen with webkit on _windows_ or _chromium_ on linux
- you can run these tests locally via yarn `test-browser --browser chromium --browser webkit`
- to debug, open `<vscode>/test/unit/browser/renderer.html` inside a browser and use the `?m=<amd_module>`-query to specify what AMD module to load, e.g `file:///Users/jrieken/Code/vscode/test/unit/browser/renderer.html?m=vs/base/test/common/strings.test` runs all tests from `strings.test.ts`
- to debug, open `<vscode>/test/unit/browser/renderer.html` inside a browser and use the `?m=<amd_module>`-query to specify what AMD module to load, e.g `file:///Users/jrieken/Code/vscode/test/unit/browser/renderer.html?m=vs/base/test/common/strings.test` runs all tests from `strings.test.ts`
- to run only a subset of tests use the `--run` or `--glob` options
**Note**: you can enable verbose logging of playwright library by setting a `DEBUG` environment variable before running the tests (https://playwright.dev/docs/debug#verbose-api-logs)
## Run (with node)
yarn run mocha --ui tdd --run src/vs/editor/test/browser/controller/cursor.test.ts
yarn run mocha --ui tdd --run src/vs/editor/test/browser/controller/cursor.test.ts
## Coverage
@@ -34,8 +35,8 @@ The following command will create a `coverage` folder at the root of the workspa
**OS X and Linux**
./scripts/test.sh --coverage
./scripts/test.sh --coverage
**Windows**
scripts\test --coverage
scripts\test --coverage