How to Test a Website in Visual Studio Code

Direct answer: “Testing a website in Visual Studio Code” can mean four different activities: previewing the rendered page, debugging browser JavaScript, running automated tests, or checking a complete user journey against acceptance criteria. VS Code supports all four through its integrated browser, browser debugger, Testing view, tasks, and extensions. Choose the workflow that answers your immediate question, then combine them for reliable coverage.

1. Decide what you need to test

Question	Best workflow	Evidence
Does the page look and behave correctly right now?	Integrated or external browser	Rendered content, interactions, screenshots, console output
Why does client-side code fail?	Edge or Chrome debugger	Breakpoints, variables, call stack, source maps
Does a known behavior keep working?	Framework test extension and Testing view	Repeatable test results and optional coverage
Can a user complete a journey?	Browser interaction against acceptance criteria	Visible states, navigation, validation messages, network and console evidence

VS Code does not provide one universal website-testing framework. Test discovery and result reporting depend on your language, framework, and installed extension. The Testing view centralizes supported discovery, execution, debugging, results, and coverage.

2. Start the website locally

Use the development command documented by your project. VS Code does not automatically start every framework’s server.

# Examples only; use the command defined by your project
npm install
npm run dev

# Or, for a static folder
python -m http.server 8000

Record the URL printed by the server, such as http://localhost:3000. If the page calls an API, start that service too and confirm its URL, credentials, and CORS configuration.

3. Preview and inspect the rendered page

Open the project in desktop VS Code.
Start its development server.
Open the local URL in VS Code’s integrated browser, or open it in Edge or Chrome.
For a static file, open the HTML file directly in the integrated browser.
Use browser developer tools to inspect elements and review console output.

The integrated browser documentation covers opening web applications and local HTML files, developer tools, and browser feedback. Check the visible page at the viewport sizes your users need, then exercise links, forms, menus, keyboard navigation, and error states.

A practical manual checklist

The expected URL loads without a redirect loop.
Fonts, images, CSS, and JavaScript load successfully.
The browser console has no unexpected errors.
Primary navigation reaches the intended destinations.
Forms show useful errors for invalid input and complete the success path for valid input.
Loading, empty, offline, and server-error states are understandable.
Keyboard focus is visible and the main actions work without a mouse.
The layout remains usable at narrow and wide viewport sizes.

4. Debug browser JavaScript in VS Code

Use the built-in debugger with Microsoft Edge or Google Chrome. It supports JavaScript and TypeScript running in the browser, as well as Node.js. A launch configuration connects a debugging session to your local URL.

Create .vscode/launch.json:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "pwa-chrome",
      "request": "launch",
      "name": "Launch local website",
      "url": "http://localhost:3000",
      "webRoot": "${workspaceFolder}"
    }
  ]
}

Open Run and Debug, select Launch local website, and start it. Set a breakpoint in a source file, reproduce the action, and inspect local variables, the call stack, and exception details.

For Edge, use pwa-msedge instead of pwa-chrome. If a browser is already running, use an attach configuration supported by the browser-debugging extension. The browser debugging guide documents launch and attach modes, source maps, and browser debugging limitations.

Source maps and debugger failures

Your breakpoint is hollow or never binds: verify that the URL maps to the workspace files and that production or development source maps are generated.
The Debug Console reports inaccessible source maps: fix the map URL or server permissions; the debugger cannot show original TypeScript or bundled sources without a readable map.
The wrong page opens: check the configured URL, port, path, and active development server.
A focus bug disappears while debugging: browser focus can change during a debug session. Reproduce focus-sensitive behavior in a normal browser window too.

5. Run automated tests from the Testing view

Identify the framework already used by the project.
Install a VS Code extension that supports that framework.
Open the beaker-shaped Testing view.
Allow test discovery if the extension supports it.
Run or debug the whole suite, a file, or an individual test.
Review inline status and the Test Results panel. Coverage appears only when the extension supports publishing it.

Official examples include Jest, Mocha, Pytest, and JUnit; they are examples of extension support, not a requirement that every website use one of them. See the Testing documentation and the Testing API for extension-provided discovery and result publishing.

Example: a browser-facing test command

{
  "scripts": {
    "test": "jest",
    "test:watch": "jest --watch",
    "test:e2e": "playwright test"
  }
}

Use the commands your project already defines. A VS Code task can make a command repeatable:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Run website tests",
      "type": "shell",
      "command": "npm test",
      "group": "test",
      "problemMatcher": []
    }
  ]
}

Tasks run commands but do not automatically populate the Testing view. The framework extension must provide that integration.

6. Test a complete user journey

Write acceptance criteria as observable outcomes before clicking through the page. For example:

Submitting an empty sign-up form displays a required-field message.
Submitting a valid address shows a success state.
Refreshing the success page preserves or clearly resets the expected state.
Navigation reaches the account dashboard.

Run the journey in a browser, inspect the rendered content, capture evidence when useful, and review console errors. A browser feedback loop can combine page content, screenshots, and console output; VS Code documents this approach for browser tools and agents.

7. Capture a reproducible screenshot

For a local manual check, use the browser’s screenshot command or an installed testing framework. Record the URL, viewport, browser, test data, and commit so another developer can reproduce the result. Screenshots show visual output; they do not prove that hidden JavaScript errors or accessibility issues are absent.

8. Or skip the browser setup

ScreenshotNeo provides a website screenshot API and MCP server. It accepts one GET request and returns a PNG, JPEG, WebP, or PDF. Before capture, it accepts cookie or consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed as clean shots; response headers identify the page verdict and billing status.

See the ScreenshotNeo API documentation for all options. Minimal calls:

cURL

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Python

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)

Node.js

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Useful capture controls include full-page screenshots with lazy images loaded, CSS-element capture, dark mode, 12 device presets or custom viewports, retina scale, PDF paper size and margins, custom CSS and JavaScript, click-before-capture, selector waits, delays, network-idle waits, ad/tracker/request blocking, headers, cookies, user agents, Authorization, timezone, geolocation, transparent backgrounds, resizing, chosen cache TTLs, signed public image links, asynchronous jobs with signed webhooks, bulk capture of up to 100 URLs per call, usage reporting, and an OpenAPI specification. Parameter names used by other screenshot APIs also work, which can simplify migration.

An MCP server supplies take_screenshot, get_page_info, and capture_pdf to Claude, Cursor, and other MCP clients. Every feature is available on every plan: 1,000 shots per month are free with no card; paid plans start at $5 for 3,000 shots. Other plans are Growth $15/15,000, Pro $39/60,000, Scale $99/250,000, and Business $249/1,000,000; annual billing provides two months free.

Create a free ScreenshotNeo account to get 1,000 screenshots each month with no card.

9. Troubleshooting checklist

Symptom	Likely cause	Fix
Integrated browser shows a blank page	Server is stopped, wrong port, or app crashed	Read the terminal output, restart the documented command, and open the exact URL.
CSS or images are missing	Bad asset path, proxy rule, or failed request	Inspect the Network panel and use paths that work from the deployed base URL.
Console has cross-origin errors	API does not allow the page origin	Configure the API’s CORS policy for the development origin or use the project’s supported proxy.
Tests are not discovered	Missing or incompatible extension, unsupported naming, or bad test command	Install the framework extension, verify its settings, and run the project command directly.
Tests pass locally but fail in CI	Different browser, environment variables, timezone, data, or timing	Pin the required environment, remove shared state, and collect CI screenshots, logs, and traces.
Debugger opens the wrong source	Source-map or `webRoot` mismatch	Correct `webRoot`, rebuild maps, and verify the browser URL matches the launched app.
VS Code for the Web lacks a feature	Browser version of VS Code has no desktop terminal or debugger and supports fewer extensions	Use desktop VS Code for local server and browser debugging, or run tests in an external environment.

10. Reliability, performance, and cost notes

Repeatability: Save test commands, browser configuration, viewport, seed data, and acceptance criteria in the repository.
Timing: Prefer waiting for a meaningful selector or network-idle state over arbitrary sleeps; keep a short delay only when the UI truly needs it.
Isolation: Use fresh test data and reset browser state so one test cannot change another test’s result.
Debug speed: Run one focused test while investigating, then run the full suite before merging.
Evidence: Store screenshots and console logs with the failing test or commit, while avoiding secrets and personal data.
VS Code for the Web: It is useful for editing and some extension workflows, but its missing terminal and debugger and limited extension support can prevent a complete local website test.
Screenshot API cost: ScreenshotNeo bills only clean shots. Failed loads, bot checks, blank pages, timeouts, and cache hits are not billed, and the response headers expose the verdict and billing result.

FAQ

Can VS Code test any website without an extension?

You can preview and manually inspect a page, and debug browser JavaScript with the built-in tools. Automated discovery and reporting require an extension that supports the project’s framework.

Should I use the integrated browser or Chrome?

Use the integrated browser for a quick in-editor feedback loop. Use Edge or Chrome when you need the browser’s full developer-tool workflow or want to reproduce a user environment directly.

Does running a VS Code task make a test appear in Testing?

No. A task runs a command. A compatible testing extension must discover tests and publish their results to the Testing view.

Why do visual checks and automated tests both matter?

Visual checks reveal rendered and interaction problems in a real browser. Automated tests provide repeatable regression checks. Neither replaces the other.

What is the quickest way to automate screenshots?

Use the ScreenshotNeo request above, or its MCP tools when an AI client needs screenshots, page information, or PDFs as part of a workflow.