…
|
||
---|---|---|
.. | ||
src | ||
test | ||
tools | ||
.gitignore | ||
Audit.md | ||
package.json | ||
README.md | ||
tsconfig.json | ||
yarn.lock |
VS Code Smoke Test
Run
# Dev
yarn smoketest
# Build
yarn smoketest --build PATH_TO_BUILD
Run for a release
You must always run the smoketest version which matches the release you are testing. So, if you want to run the smoketest for a release build (eg release/1.22
), you need that version of the smoke tests too:
git checkout release/1.22
yarn
yarn smoketest --build PATH_TO_RELEASE_BUILD
Debug
--verbose
logs all the low level driver calls made to Code;-f PATTERN
filters the tests to be run. You can also use pretty much any mocha argument;--screenshots SCREENSHOT_DIR
captures screenshots when tests fail.
Develop
Start a watch task in test/smoke
:
cd test/smoke
yarn watch
Pitfalls
-
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 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 thewaitForActiveElement
API. Many tests use this whenever they need to wait for a specific element to have focus. -
Beware of timing. You need to read from or write to the DOM... but is it the right time to do that? Can you 100% guarantee that that
input
box will be visible at that point in time? Or are you just hoping that it will be so? Hope is your worst enemy in UI tests. Example: just because you triggered Quick Open withF1
, it doesn't mean that it's open and you can just start typing; you must first wait for the input element to be in the DOM as well as be the current active element. -
Beware of waiting. Never wait longer than a couple of seconds for anything, unless it's justified. Think of it as a human using Code. Would a human take 10 minutes to run through the Search viewlet smoke test? Then, the computer should even be faster. Don't use
setTimeout
just because. Think about what you should wait for in the DOM to be ready and wait for that instead.