microsoft/vscode
1
0
Fork 0
mirror of https://github.com/microsoft/vscode.git synced 2026-07-10 05:28:19 -05:00
Code Issues Packages Projects Releases 177 Wiki Activity

quick access - more cleanup

Browse Source
This commit is contained in:
Benjamin Pasero
2020-03-26 13:51:05 +01:00
parent 7eee4d02e7
commit e80f8a5da9
12 changed files with 12 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
test/automation/src/application.ts
View File

@@ -146,7 +146,7 @@ export class Application {
}
// wait a bit, since focus might be stolen off widgets
// as soon as they open (e.g. quick open)
// as soon as they open (e.g. quick access)
await new Promise(c => setTimeout(c, 1000));
}
}

2
test/smoke/README.md
View File

@@ -78,6 +78,6 @@ yarn watch
- 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_.
- 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 `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 with `F1`, 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 **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 `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 Access with `F1`, 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.

6
test/smoke/src/areas/search/search.test.ts
View File

@@ -57,8 +57,8 @@ export function setup() {
});
});
describe('Quick Open', () => {
it('quick open search produces correct result', async function () {
describe('Quick Access', () => {
it('quick access search produces correct result', async function () {
const app = this.app as Application;
const expectedNames = [
'.eslintrc.json',
@@ -75,7 +75,7 @@ export function setup() {
await app.code.dispatchKeybinding('escape');
});
it('quick open respects fuzzy matching', async function () {
it('quick access respects fuzzy matching', async function () {
const app = this.app as Application;
const expectedNames = [
'tasks.json',

2
test/smoke/src/areas/statusbar/statusbar.test.ts
View File

@@ -28,7 +28,7 @@ export function setup(isWeb) {
await app.workbench.statusbar.waitForStatusbarElement(StatusBarElement.SELECTION_STATUS);
});
it(`verifies that 'quick open' opens when clicking on status bar elements`, async function () {
it(`verifies that 'quick input' opens when clicking on status bar elements`, async function () {
const app = this.app as Application;
await app.workbench.statusbar.clickOn(StatusBarElement.BRANCH_STATUS);