DEV Community: Maciek Chmura

How to test a web app built with Claude Code or Cursor before you ship

Maciek Chmura — Tue, 03 Nov 2026 09:16:21 +0000

Your coding agent says the feature is done. The build is green. Then a user tells you they can't log in.

This happens a lot with apps built in Claude Code or Cursor. The agent checks that the code compiles and that the tests it knows about pass. It doesn't check that a real person can still sign up, log in and pay. That part is still your job.

Here's the short answer: pick the few flows that must never break, make the agent run fast checks before it stops, and run those flows in a real browser against a preview deploy before every release. The rest of this post is the step-by-step version I use.

1. Write down your critical flows first

Before you write any test, write a list. Not every page. Only the journeys a customer would notice first if they broke.

For most SaaS apps that's something like:

Sign up with a new email
Log in and log out
Reset a password
The main "create" action (a project, a post, an order)
Checkout or upgrade to a paid plan
One settings change people actually use

Keep it under ten. Put it in a file in the repo, like CRITICAL_FLOWS.md, so both you and the agent can read it. A one-line description per flow is enough:

# Critical flows
1. Sign up: new email -> confirm -> lands on empty dashboard
2. Log in: existing user -> dashboard shows their projects
3. Create project: name it -> it appears in the list after reload
4. Upgrade: pick Pro -> test card -> plan shows "Pro" in settings

The "after reload" part matters. A lot of agent bugs only show when the data has to come back from the server.

2. Tell the agent about the list, and about your test command

Agents follow rules files: CLAUDE.md for Claude Code, .cursor/rules or AGENTS.md for Cursor. Add two things:

## Before you finish a task
- Run `npm run typecheck && npm test` and fix anything that fails.
- If you touched auth, billing or the dashboard, list which items in
  CRITICAL_FLOWS.md your change could affect.

The second line is cheap and useful. It makes the agent tell you the blast radius of its change, so you know what to check.

But rules are advice. The agent can still skip them.

3. Make the fast checks a gate the agent can't skip

Claude Code has hooks, which run a command at fixed points. A Stop hook runs when the agent is about to finish. If the command exits with code 2, Claude Code keeps the agent working and shows it the error.

In .claude/settings.json:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "npm run typecheck 1>&2 && npm test --silent 1>&2 || exit 2"
          }
        ]
      }
    ]
  }
}

Keep this command fast. Typecheck and unit tests, maybe your access-control tests. If it takes five minutes on every turn, you'll turn it off. Browser tests belong later in the pipeline.

Cursor has its own hooks feature too. Check its docs for the current format, since it has been changing.

4. Deploy every change to a preview URL

You can't test the app a user sees from inside the repo. You need it running.

Vercel, Netlify and Cloudflare Pages all build a unique preview URL for each branch or pull request. Turn that on. Now every change the agent makes has a real address you can open, with nothing mocked.

Use a separate test database or seeded test accounts for previews. You don't want a signup test creating real users in production.

5. Run the critical flows in a real browser

This is the step that catches the things unit tests miss: a button whose onClick was dropped, a form that submits but never saves, a redirect loop after login.

If you write code-based tests, Playwright is a good default. Here is the login flow from the list above:

import { test, expect } from '@playwright/test';

const BASE_URL = process.env.PREVIEW_URL ?? 'http://localhost:3000';

test('existing user can log in and sees their projects', async ({ page }) => {
  await page.goto(`${BASE_URL}/login`);
  await page.getByLabel('Email').fill(process.env.TEST_USER_EMAIL!);
  await page.getByLabel('Password').fill(process.env.TEST_USER_PASSWORD!);
  await page.getByRole('button', { name: 'Log in' }).click();

  await expect(page).toHaveURL(/\/dashboard/);
  await expect(page.getByText('My first project')).toBeVisible();
});

Two habits make these tests worth having:

Assert an outcome, not a page load. "The project is in the list" is a check. "The dashboard opened" is barely one.
Make sure the test can fail. Break the page on purpose once, and confirm the test goes red. A test that passes on a broken page is worse than no test.

Use role and label selectors (getByRole, getByLabel) rather than CSS classes. Agents rename classes all the time. They change visible button text much less often.

6. Check the API, not just the screen

Some bugs look fine in the browser. The API returns 200 OK, the page shows a spinner and then nothing, and the real problem is a wrong field in the JSON.

For the endpoints behind your critical flows, check more than the status code:

test('projects API returns the user\'s projects', async ({ request }) => {
  const res = await request.get(`${BASE_URL}/api/projects`, {
    headers: { Authorization: `Bearer ${process.env.TEST_USER_TOKEN}` },
  });
  expect(res.status()).toBe(200);
  const body = await res.json();
  expect(Array.isArray(body.projects)).toBe(true);
  expect(body.projects[0]).toHaveProperty('name');
});

Also try one request as the wrong user. Agent-written backends often forget to check that a record belongs to the person asking for it.

7. Wire it into CI and block the merge

Run the same checks on every pull request, whoever or whatever wrote it:

name: checks
on: pull_request
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run typecheck && npm test
      - run: npx playwright install --with-deps chromium
      - run: npx playwright test
        env:
          PREVIEW_URL: ${{ vars.PREVIEW_URL }}
          TEST_USER_EMAIL: ${{ secrets.TEST_USER_EMAIL }}
          TEST_USER_PASSWORD: ${{ secrets.TEST_USER_PASSWORD }}

Getting the preview URL for each PR depends on your host. Most of them post a deployment status you can wait for, then read the URL from. Mark the job as required in your branch protection settings so a red run actually blocks the merge.

8. Feed failures back to the agent

When a browser check fails, don't just tell the agent "a test is red." Give it the flow, the step that failed, and what the page showed. Paste the Playwright error and the trace or screenshot.

A message like "After clicking Log in, the page stayed on /login and showed 'Invalid session'" gets you a much better fix than a stack trace alone.

9. Still do a quick manual pass before a release

Tests only check what someone wrote down. Before a bigger release, click through your critical flows yourself once, on a phone and in Safari. Try a payment failure in test mode. It takes ten minutes and catches the things nobody thought to automate.

The short version

List your critical flows.
Put the list and your test command in the agent's rules file.
Gate the agent on fast checks with a hook.
Deploy every change to a preview URL.
Run the critical flows in a real browser and check the API behind them.
Block merges on red, feed failures back to the agent, and do a manual pass before releases.

None of this needs a QA team. It needs a short list and the habit of checking it every time.

I'm building AlwaysQA, which checks login, checkout and other critical flows in a real browser after your coding agent ships a change. It only checks the flows you describe, and it doesn't replace your unit tests.

Automated regression testing for web applications: what to automate and what to keep human

Maciek Chmura — Mon, 07 Sep 2026 07:08:08 +0000

A form took two days to regression test. The hard part wasn’t the clicking.

A multi-page quiz. More than ten questions. Different behavior depending on the account and user role. A calculated result that had to be saved correctly.

A full regression pass took the QA team about two days.

That’s how one of AlwaysQA’s founders remembers testing a feature at a former workplace. Each individual path looked manageable. The work grew when the team had to repeat it across accounts, roles, answer combinations, and expected results.

Other development work waited while QA completed the checks.

The obvious response is: “Just automate it.”

But automate what, exactly?

Clicking through the pages was only part of the job. Someone still had to define the account state, choose the right answers, know the expected calculation, and verify that the application saved the result.

The hard part wasn’t teaching a browser to click Next. It was maintaining a trustworthy definition of what should happen.

That’s where I’d start a regression automation project—not with the tool.

First, separate regression testing from checking a fix

Suppose you fix a bug that calculates the wrong result for one user role.

Checking that the calculation now works is confirmation testing: did the fix resolve the defect?

Checking that other roles still receive the correct results is regression testing: did the change break behavior that previously worked?

The ISTQB Foundation Level syllabus makes this distinction. Regression effects can appear in the changed component, elsewhere in the application, or in connected systems.

Automation changes how those checks run. It doesn’t change their purpose.

A regression check can be a unit test, an API test, a browser test, or a manual check. You don’t need to drive a browser for every regression risk.

Don’t turn the entire manual checklist into browser tests

In the quiz example, a QA engineer had to sign in with a prepared account, complete the role-specific form, consult a separate source of truth, exercise valid and invalid paths, and verify the calculated and saved result.

Then repeat the process for the next scenario.

The team didn’t have automation for this workflow. A code-based browser suite appeared expensive to create and maintain because it would need to represent all those variations.

That doesn’t mean Playwright or Cypress couldn’t handle it. It means that “write an end-to-end test” wasn’t a complete solution.

Before choosing a tool, I’d split the problem into three questions:

Question	Where I’d start
Does this answer set produce the correct calculation?	Unit tests
Are permissions enforced and results stored correctly?	API or integration tests
Can a user with this role complete the quiz and view the expected saved result?	Browser end-to-end tests

These checks overlap intentionally, but they prove different things.

A unit test can exercise calculation edge cases without signing in and answering ten questions every time. An API test can check authorization and persistence without rendering the form. A browser test can check whether the pieces work together from the user’s perspective.

Cypress’s testing guidance describes these different scopes and the additional setup, infrastructure, and maintenance that end-to-end testing can involve.

Use the browser to prove the journey. Don’t make it carry every internal rule.

Your first automated workflow should be bounded, not impressive

The most time-consuming feature isn’t automatically the best first automation project.

For the quiz, I wouldn’t begin with every role and answer combination. I’d choose one important role, one prepared account, and one defined answer path.

A useful first candidate has three properties:

It matters. A failure would block a meaningful user task or create release risk.
It repeats. QA already performs substantially the same check across releases.
It can be specified. The starting state and expected result are clear.

That last property is easy to underestimate.

“Check that the quiz works” is not a test specification.

“Using a prepared account with role A, submit answer set 01 and verify that the expected result is displayed and available when the saved submission is reopened” is much closer.

The first asks a tool to discover the requirements and judge the implementation simultaneously. The second gives it a defined question to answer.

Write the test contract before the test script

For a first browser check, I’d write something like this:

Scenario
  Role A completes answer path 01.

Starting state
  Staging environment.
  Dedicated test account with role A.
  Known quiz version.
  No existing submission that would change this path.

Test data
  A defined answer set.
  An independently established expected result.

Actions
  Sign in.
  Open the quiz.
  Complete the defined answer path.
  Submit.
  Reopen the saved submission.

Pass conditions
  The displayed result matches the expected result.
  The reopened submission shows the expected saved result.

Failure evidence
  Account role and scenario identifier.
  Answers submitted.
  Expected result versus observed result.
  The step where behavior diverged.
  Relevant screenshots, trace, or logs where available.

This is a test-design example, not a tool-specific configuration format.

Notice what’s missing: selectors, browser APIs, and prompts.

Those come later. First, the team needs to agree on what the check must prove.

Also, keep the expected result independent of the production logic being tested. If your test calculates its expectation by calling the same broken formula, both sides can agree while the behavior is wrong.

For the quiz, the existing source of truth is therefore part of the automation design—not an annoying detail to resolve after the browser script is finished.

Test data is part of the test

A well-written script won’t rescue an uncontrolled starting state.

Suppose the first run passes, but the second fails because the account has already submitted the quiz. Or another test changes its role. Or someone edits the answer data while the run is in progress.

You now have a result to investigate, but it may say more about the test setup than the application.

Playwright’s best practices recommend isolated tests with their own state to improve reproducibility and prevent failures from cascading between tests.

For a state-changing workflow, answer this before scheduling it:

What makes the next run start from the same meaningful conditions as the previous one?

That could mean resetting a dedicated account, creating fresh test data, or using a supported cleanup process. The implementation depends on the application.

The requirement doesn’t: the starting state must be deliberate.

And don’t confuse an interface signal with every underlying guarantee. A success toast is evidence that a message appeared. Reopening a saved submission checks more of the user-visible behavior. Backend persistence rules still deserve their own lower-level checks.

AI can change the execution. It doesn’t remove the assertions.

Once you’ve justified a browser-level check, you can choose how to execute it.

With code-driven automation, the team specifies actions and assertions explicitly. That can be a good fit when you want precise control over the path and already have the engineering capacity to maintain it.

With AI-guided browser execution, you can describe the user’s goal and evaluate an alternative to maintaining fixed interaction steps.

But the underlying contract remains:

Start from this state, attempt this workflow, and verify this observable outcome.

AI doesn’t remove the need for test data, expected results, safe boundaries, or useful evidence.

“Use AI to test the quiz” is no more complete than “use Playwright to test the quiz.”

Neither approach should get to invent the correct result because the page looks plausible.

Human exploration belongs alongside both approaches, especially when the behavior is new, requirements are ambiguous, or someone needs to notice a problem that wasn’t anticipated in the test.

An inconclusive run isn’t the same as a product failure

Before automating a workflow, decide how you’ll interpret the result.

There are at least three useful distinctions:

Passed: the check reached the specified outcome and collected sufficient evidence.

Failed: the observed behavior contradicted the expected behavior.

Inconclusive: the run couldn’t establish a reliable verdict.

For example, an incorrect quiz result is evidence of a failed check. An unavailable test fixture that prevents the scenario from starting is not, by itself, evidence that the quiz calculation is broken.

Both need attention, but they need different investigations.

A report should make that distinction visible. Otherwise, QA ends up replaying the entire workflow just to determine whether the application failed, the setup failed, or the runner got stuck.

The same principle applies to passing results. A green status is only useful when you understand what was actually verified.

One passing path is not a certificate that the application is regression-free.

Where AlwaysQA fits

Disclosure: I’m building AlwaysQA, an AI-guided browser QA product.

Its test-case model follows the same basic structure: a starting URL, plain-language instructions, and an observable success condition.

A run returns Passed, Failed, or Needs Attention, with evidence that can include a summary, observations, an action timeline, and a temporary replay. Needs Attention keeps an inconclusive run separate from an observed failure.

Checks can run on demand or on daily or weekly schedules. The workflow is described in How AlwaysQA works.

That makes it one option for the browser-execution part of this approach. It doesn’t replace the expected-result model, lower-level tests, or human judgment.

And the two-day quiz example is a recollection of a manual testing problem—not a before-and-after result from using AlwaysQA.

Run a one-workflow pilot before expanding

You don’t need a large suite to find out whether automation is helping.

You need one check that earns the team’s trust.

1. Record the manual baseline

Measure how often the workflow is checked, how long it takes, what setup it requires, and what other work waits for it.

Use your team’s actual experience. The quiz’s two-day regression pass isn’t a benchmark for another application.

2. Implement one complete path

Choose one role and one data variant. Define the starting state, expected result, and failure evidence.

Handle cleanup or reset before introducing repeated runs.

3. Review the early results

Check that Passed means the intended behavior really happened. Check that Failed and inconclusive results provide enough information to investigate.

Where it’s safe, deliberately introduce a known failure in a controlled test environment. A check that stays green when its success condition is violated hasn’t earned your trust.

Run the pilot on demand while you work through problems in the specification, data, or execution.

4. Measure the work that remains

Don’t measure success only by counting automated runs.

Compare the manual effort removed with the effort spent reviewing results, investigating false alarms, and maintaining the check. Notice whether QA still has to repeat the workflow because the evidence isn’t convincing.

A test that runs every day but gets manually repeated every day hasn’t removed the task.

5. Expand one variable at a time

Once the first path is trustworthy, add another role, answer set, or important edge case.

Change the execution cadence deliberately too. A daily schedule is useful only when the workflow’s risk justifies it and the test state can be prepared safely.

Small expansions make it easier to identify which new assumption caused a problem.

Automate repetition. Keep judgment.

The goal isn’t to remove QA professionals from the process.

People still need to decide which risks matter, define correct behavior, explore unexpected paths, investigate failures, and judge whether a release is acceptable.

The goal is to stop spending the same human attention on a well-understood check every time the application changes.

For the quiz, I wouldn’t start by asking:

How do we automate every combination?

I’d ask:

What is one important path we can specify, repeat, and trust?

Then I’d build outward from there.

What’s the workflow your team keeps regression-testing by hand—and what makes it difficult to automate: the interactions, the test data, or knowing the correct result?

Building QuickArchViz: turning 3D models into renders

Maciek Chmura — Fri, 24 Apr 2026 13:07:08 +0000

A few months ago, I started building QuickArchViz — a tool that turns 3D model screenshots into architectural visualizations in seconds.

The idea came from a very simple frustration I had in the past when I was still an architect:
My models were ready, but I still needed to make the visualizations for the client

Rendering takes time. It costs money. And every client meeting resets the whole process.

I wanted something faster. Something closer to how architects actually work.

So I started building it - now that I have over 10+ years of experience in programming.

What QuickArchViz does

You upload a screenshot from your 3D model (SketchUp, Revit, Archicad — whatever).

The system:

keeps your geometry and camera
enhances materials, lighting, environment
generates a presentation-ready visual

No exports. No rendering settings. No waiting hours.

Just:
upload → choose style → generate

The stack

Nothing exotic. The interesting part is not the stack - it’s how the pieces work together.

Backend

Laravel (API + orchestration)
Postgres (multi-tenant, render tracking, token usage)

Frontend

React + Inertia
simple UI, focused on speed (upload → result)

AI generation

image generation via external APIs (currently experimenting heavily)
prompt engineering is doing most of the heavy lifting

Infra

VPS (Laravel Forge)
no overkill, trying to stay lean

The hard part: making AI behave like an architect

The biggest challenge wasn’t “generate a pretty image”.

It was:

don’t break the architecture

Most AI image tools will happily:

change proportions
move windows
redesign the building

That makes them useless for real workflows.

So the core of the system is actually the prompt framework, not the model.

Core constraints (this took weeks to get right)

Every generation follows strict rules:

preserve exact geometry
preserve camera position
preserve hard surfaces (paths, roads)
do not redesign the building

Then only enhance:

lighting
materials
environment

Styles are harder than they look

I thought styles would be easy.

They’re not.
Example: Golden hour

Most models go straight into:

orange Instagram sunset in Bali

What I needed was:

subtle, European, architectural light

So styles became controlled systems, not just “vibes”.

Current styles

Clean daylight (default, most reliable)
Golden hour (recently fixed, less saturated)
Overcast / Nordic
Evening / blue hour
Artistic (marker, watercolor, concept)

Each one has its own prompt logic.

UX decisions (what actually matters)

I’m trying to remove every possible friction point.

Key decisions:

no file exports required → screenshot is enough
no settings → just styles
no queue UI → simple “processing” state
pay-as-you-go (no subscription)

What I’m working on now

improving daylight realism (less “CGI”, more “photo”)
refining golden hour (already toned down)
adding more artistic styles
improving landing page conversion

If you want to check it out:

👉 quickarchviz

Final thought

This is one of those products where:

the tech is not the hardest part
the UX is not the hardest part

The hardest part is:

making AI respect reality

Still working on that.

If you’re building something in this space or fighting similar issues (especially consistency / prompting / positioning), curious what worked for you 👇