Dev testing

Validate your local, uncommitted code changes against a running development server before you push, so issues are caught while context is fresh.

Dev testing is a fast feedback loop for developers. Test Companion analyzes the changes in your working directory, launches a browser against your local development server, and verifies that your changes behave as expected. You catch regressions and broken paths in seconds, while the code is still in your editor and the reasoning is still in your head.

You do not select dev testing as a mode. Describe a local code change you want to verify, or click the Test the code changes (Dev Testing) quick action on the chat home screen, and Test Companion handles the rest.

When to use dev testing

Dev testing is the right fit when you have made local code changes and want to confirm the behavior before pushing. Common scenarios include verifying a bug fix on the page where the bug appeared, checking a UI change such as a new button or modified layout, validating that a refactored component still renders correctly, and confirming that a backend change has not broken the front-end integration.

Dev testing is not a replacement for formal test automation. It is a one-off verification loop that helps you catch issues during development. Findings from a dev testing session can inform the formal test cases or automation scripts you create later, but the session itself is not a reusable artifact.

Before you begin

You need three things in place before you start a dev testing session.

• A running local development server, such as localhost:3000 or any other URL where your application is reachable from the machine running Test Companion.
• Uncommitted changes in your working directory, or a recent set of commits you want to verify. Test Companion uses your git diff to scope what to test.
• The Test Companion extension installed in your IDE and connected to your BrowserStack account. See Get started if you have not completed setup.

Run a dev testing session

The procedure below covers the most common path. Adjust the prompt to match your scenario.

1. In the Test Companion panel, click the Test the code changes (Dev Testing) quick action. The chat input is pre-filled with a starter prompt.
2. Edit the prompt to describe what you changed and what to verify. Be specific. State the page or flow to test, the expected behavior, and any edge cases that matter.
3. Attach context. At minimum, attach the relevant file or folder using + or @. If your change is scoped to specific commits, attach them using @ > Git Commits.
4. Include the URL of your local development server in the prompt (for example, localhost:3000).
5. Press Enter. Test Companion analyzes your changes, opens a browser against the local URL, navigates to the relevant pages, and exercises the changed behavior.
6. Review the results. Test Companion returns a pass or fail verdict for each scenario it checked, with screenshots of the relevant page states and a summary of what it observed.

Example prompts

The examples below show how to phrase prompts for common dev testing scenarios. Replace the placeholder details with the specifics of your change.

Verify a bug fix

I fixed a bug where clicking "Save" on an empty profile form crashed
the page. Open localhost:3000/profile, clear all form fields, click
Save, and verify that a validation error is shown instead of a crash.

Check a UI change

I changed the navigation from a top tab bar to a left sidebar.
Open localhost:3000, verify that the left sidebar is visible,
and confirm that all five navigation items (Home, Search, Cart,
Orders, Profile) are listed.

Validate a backend integration

I connected the Home page to a new API endpoint for product
recommendations. Open localhost:3000, scroll to the
"Recommended for You" section, and verify that product cards
are displayed (not an error message or empty state).

Test a specific viewport

A teammate reported that the checkout page layout breaks at small
desktop widths. Open localhost:3000/checkout at 1024 by 768,
and verify that all form fields and the Pay button are visible
without horizontal scrolling.

What dev testing returns

After the session completes, Test Companion returns a structured report with three parts.

The verdict states whether the expected behavior was observed. If a scenario failed, the verdict names the scenario and summarizes the failure in one or two sentences.

The screenshots show the state of the page at each meaningful step. Screenshots are taken at the start of the session, at each user-facing assertion, and on any unexpected error.

The observations list any related issues Test Companion noticed during the session, even if they were outside the scope of your prompt. Examples include console errors, slow network requests, or accessibility warnings on the same page.

Dev testing compared to other capabilities

Dev testing serves a different purpose than the other built-in capabilities. The table below clarifies when to use dev testing over the alternatives.

Dev testing reduces the number of defects that reach the QA team. It does not replace the formal test suite. Use the two together.

Best practices for effective dev testing

Following best practices helps you get the most value out of dev testing.

• Be specific about what to verify. Test the login page is too broad.
  

  Instead, write: Open localhost:3000/login, enter test@example.com and an empty password, click Sign in, and verify that the password field shows the error "Password is required". This gives Test Companion enough scope to produce a meaningful result.

• Run dev testing immediately after a change. The longer you wait, the more your local state drifts from what you remember changing. Dev testing is most useful when the code in your editor matches the code under test.

• Use git context for larger changes. If you have changed several files for one feature, attach the relevant commits with @ > Git Commits. Test Companion uses the diff to focus its verification.

• Capture findings before moving on. If dev testing surfaces a bug or an unexpected behavior, copy the relevant findings into your task tracker before starting the next change.

Known limitations

The following constraints apply to dev testing in the current release.

• Dev testing analyzes the diff in your working directory and the commits you attach. It does not analyze code paths that have no associated change.
• Dev testing reports are not saved as test cases. To turn a dev testing finding into a reusable test, describe the same scenario in a new prompt and ask Test Companion to generate test cases for it.

Next steps

• Generate test cases: Convert dev testing findings into formal test cases.
• Write automation code: Turn manual scenarios into automation scripts.
• Fix flaky or failing tests: Diagnose and resolve failures in your CI/CD builds.