How to Fix “No Playwright Tests Found” in VS Code
Fix an empty Playwright Test Explorer by checking installation, workspace, config matching, CLI discovery, and extension diagnostics.
When VS Code says “No tests have been found in this workspace yet” or the Playwright panel is empty, work through this order: verify Playwright Test is installed, open the workspace that owns the tests, select the correct configuration, check testDir and testMatch, compare discovery with the CLI, then inspect extension output and versions.
The Playwright VS Code extension discovers tests from the Playwright package and configuration in your project. An empty Test Explorer can therefore come from project setup, file matching, the selected configuration, or editor integration.
1. Confirm the extension and Playwright Test package
Install Microsoft’s official Playwright Test for VS Code extension. In the project terminal, verify that Playwright Test is installed:
npm ls @playwright/test
npx playwright --version
For a new project, open the Command Palette and run Test: Install Playwright. The extension repository lists Playwright v1.38 or newer as a requirement, so treat the project and extension versions as compatibility checks.
2. Open the correct VS Code workspace
Open the folder containing the project’s package.json, Playwright config, and test files. Opening a parent monorepo folder or a sibling package can make the extension inspect a project that has no Playwright tests.
If the repository contains multiple configurations, open the Playwright sidebar, select its gear control, and choose the playwright.config.ts (or JavaScript) file that owns the tests. VS Code supports multiple Playwright configurations, but discovery only occurs for the configuration currently selected by the extension.
3. Check the Playwright config and file layout
Start with a minimal configuration and a conventional test file:
import { defineConfig, devices } from '@playwright/test';
export default defineConfig({
testDir: './tests',
testMatch: /.*\\.(spec|test)\\.[jt]s/,
use: {
baseURL: 'http://127.0.0.1:3000',
trace: 'on-first-retry'
},
projects: [
{ name: 'chromium', use: { ...devices['Desktop Chrome'] } }
]
});
Put a test at tests/example.spec.ts:
import { test, expect } from '@playwright/test';
test('home page has a title', async ({ page }) => {
await page.goto('/');
await expect(page).toHaveTitle(/home/i);
});
Discovery is controlled mainly by these options:
| Option | What to inspect | Typical mistake |
|---|---|---|
testDir |
Directory Playwright scans for tests | Tests are in e2e/ but config scans tests/ |
testMatch |
Glob or regular expression for test filenames | Files end in .e2e.ts but the pattern only accepts .spec.ts |
testIgnore |
Patterns excluded from discovery | A broad ignore rule excludes the entire test directory |
projects |
Named browser or environment projects | The extension is switched to a project with no matching files |
| Config location | Which config file is loaded | VS Code selected a different config in a monorepo |
Playwright’s TestConfig reference documents matching and directory options. Check the real paths and names on disk against those values; a file that looks like a test is invisible if it does not match the selected configuration.
4. Compare discovery with the Playwright CLI
Run the same project and configuration from the integrated terminal:
npx playwright test --list
npx playwright test --config=playwright.config.ts --list
If the CLI also lists no tests, focus on testDir, testMatch, ignored paths, the selected config, and package installation. If the CLI lists tests but the Test Explorer is empty, the project can discover tests and the remaining investigation should focus on workspace selection, extension integration, and diagnostics. This is a useful diagnostic split, not a universal rule.
5. Validate test projects and configuration selection
Projects let one config define multiple browsers or environments. List the projects and run one explicitly:
npx playwright test --list --project=chromium
npx playwright test --project=chromium tests/example.spec.ts
Read the Playwright test projects documentation when a repository has dependencies, setup projects, or several browser definitions. In VS Code, select the project/configuration that contains the tests you expect to see.
6. Inspect extension diagnostics and versions
- Open View → Output.
- Choose the Playwright output channel.
- Look for config loading errors, package resolution errors, or connection failures.
- Compare the installed
@playwright/testversion with the extension requirement and the versions used by your repository.
The extension repository lists Playwright v1.38+ as a requirement. A reported 2026 issue describes a configuration connection error while CLI tests still worked; that report is environment-specific and does not establish one fix for every empty Test Explorer.
7. A repeatable diagnostic checklist
- Microsoft’s Playwright Test for VS Code extension is installed and enabled.
@playwright/testis installed in the workspace package that owns the tests.npx playwright --versionruns from the VS Code terminal.- The opened folder contains the intended
package.jsonand Playwright config. - The Playwright sidebar gear points to the intended config.
testDirexists and contains the test files.testMatchaccepts the files’ names and extensions.testIgnoredoes not exclude them.npx playwright test --listfinds the expected tests.- The Playwright Output channel contains no config or connection error.
Common errors and fixes
“No tests have been found in this workspace yet”
Cause: The extension is scanning a workspace or configuration that does not match your files. Fix: open the project root, select the correct config, then compare testDir, testMatch, and ignore rules with the filesystem.
The CLI finds tests but VS Code does not
Cause: The editor may have selected another config, workspace, project, or package installation. Fix: select the intended config from the Playwright sidebar, reopen the project root, and inspect Playwright Output for integration errors.
The CLI also finds no tests
Cause: This points first to project setup or matching rules. Fix: run npx playwright test --list --config=..., verify the config path, and temporarily compare your settings with the minimal example above.
Tests use an unexpected filename
Cause: The filename does not satisfy testMatch. Fix: rename it to a conventional *.spec.ts or *.test.ts, or update testMatch to include your project’s naming convention.
Multiple configs show different tests
Cause: Each config has independent directories, patterns, and projects. Fix: use the sidebar gear to switch configs and confirm the selected one with the CLI’s --config option.
Extension or package version mismatch
Cause: The extension and project may not satisfy the same supported range. Fix: record the extension version, VS Code version, and @playwright/test version in diagnostics, then consult the extension repository and project release notes before changing versions.
Running and debugging after discovery works
Once tests appear, use the Test Explorer to run a file, test, project, or debugging session. The extension integrates Playwright Test into VS Code for running and debugging. The same tests remain runnable from the CLI:
npx playwright test tests/example.spec.ts
npx playwright test --headed
npx playwright show-report
Keep the config in version control so teammates and CI use the same discovery rules.
Or skip the browser setup
If your goal is to capture a page image for a test report, visual baseline, or debugging artifact, ScreenshotNeo can return a screenshot with one GET request. See the ScreenshotNeo API documentation for the full option set.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp
import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before the shot. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed, and response headers identify the page verdict and billing result. Its MCP server lets AI agents use take_screenshot, get_page_info, and capture_pdf. The free plan includes 1,000 screenshots each month with no card; paid plans start at $5 for 3,000 shots. Create a free ScreenshotNeo account.
Performance, reliability, and cost notes
- Use
--listbefore a full run to check discovery without executing browsers. - Keep
testDirnarrow in large repositories so discovery does not scan unrelated files. - Use projects deliberately; each project can multiply the number of test executions.
- For CI, run the same explicit config path used locally and preserve Playwright Output when diagnosing integration failures.
- Do not assume an extension reinstall or version upgrade fixes every case; first identify whether the failure is discovery, configuration selection, or editor integration.
FAQ
Does every Playwright file need a .spec.ts suffix?
No. The suffix is conventional. Your configured testMatch determines which names are discovered.
Can VS Code use more than one Playwright config?
Yes. Select the intended config from the Playwright sidebar gear control.
Should I upgrade Playwright immediately?
Check compatibility and diagnostics first. The extension lists Playwright v1.38+ as a requirement, but that alone does not prove an upgrade will fix your project.
What is the fastest single command to verify discovery?
npx playwright test --list, followed by an explicit --config when the repository has multiple configurations.
Where can I find the official configuration details?
Use the Playwright TestConfig reference and the official VS Code setup guide.


