Lovable automated testing with Playwright smoke tests

Updated 2026-11-08

A useful smoke test answers a small question: can someone still open the app and complete its main flow after a change? Keep that check in the repository so you can run it again after dependency updates, rather than relying on a one-time preview.

This walkthrough is for a public GitHub JavaScript or TypeScript repository synced from Lovable. It adds repository-owned Playwright tests. Lovable also has browser testing that interacts with the current project preview. Ask it to verify a specific flow after a change. That preview check and a committed suite serve different purposes: the suite gives you a repeatable check for later pull requests.

Lovable’s testing overview distinguishes user-flow checks from focused frontend and backend tests. Keep both where needed. A browser smoke suite will not prove every business rule, authorization policy or database migration correct. Start with a narrow failure that would otherwise reach users unnoticed.

Choose a safe smoke-test target

Write the expected result in a sentence before asking an agent to generate a test. For example: “A signed-out visitor can open the pricing route and see the plan heading.” A page that returns an HTTP success but renders blank must fail that test. Later add one controlled journey such as signing in with a test account and saving a disposable record.

1. Use a local app or a separate test deployment with test data.
2. Identify which actions create records, send email, charge money or call external APIs.
3. Give test accounts only the access they need and keep credentials out of the public repository.
4. Decide how created records are removed without touching real users’ data.

Do not point a generated “click every button” test at production. A local frontend may still use a production backend if its configuration says so. Check the actual API destinations before running a write flow. A read-only route test is a good first step when the project has no isolated backend yet.

Add Playwright to the synced repository

Confirm the repository and synced branch using Lovable’s GitHub integration documentation. Keep test work on a review branch. The existing Lovable update guide covers the sync workflow; installing a test runner does not change which branch Lovable watches.

Use the official Playwright initializer for the manager the repository already uses. Choose one of these, not all three:

npm init playwright@latest
pnpm create playwright
yarn create playwright

Review the generated config, example tests and optional workflow before committing. Choose TypeScript if that matches your project. Keep the dependency manifest and existing manager’s lockfile together. If the repo already has Playwright, extend that configuration instead of initializing a competing suite.

Configure the app server

Playwright’s webServer option starts a local command and waits for its URL. The following is an example only for a repository whose dev script runs Vite. Lovable projects can use different frameworks; inspect yours before copying it.

import { defineConfig } from '@playwright/test';

export default defineConfig({
  testDir: './tests/smoke',
  reporter: 'html',
  use: {
    baseURL: 'http://127.0.0.1:4173',
    trace: 'retain-on-failure',
  },
  webServer: {
    command: 'npm run dev -- --host 127.0.0.1 --port 4173 --strictPort',
    url: 'http://127.0.0.1:4173',
    reuseExistingServer: !process.env.CI,
  },
});

Vite documents the host, port and strict-port flags. A fixed port makes the target explicit; strict-port fails if another process owns it. Replace the command for pnpm, Yarn or another framework, and make both URLs match. This example checks the development server. Keep the production build as a separate required check.

Assert a user-visible result

Save a test as tests/smoke/public-route.spec.ts. Replace the example route and heading with a real public page in your application. The heading below is an example accessible name for your app, not a Lovable interface label.

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

test('pricing route renders', async ({ page }) => {
  await page.goto('/pricing');
  await expect(
    page.getByRole('heading', { name: 'Choose a plan', exact: true })
  ).toBeVisible();
});

Playwright’s test guide documents role locators and assertions that wait for the expected state. Prefer those over a fixed sleep. Extend the suite with an action and its outcome: submit a test form, then assert the saved record appears. Clicking a button without asserting a result proves very little.

For an authenticated flow, use a dedicated account and a documented test setup. Test both an allowed action and a denied one where access matters. Do not weaken authorization or put an administrative backend key in browser code to make the test pass.

Run the suite and investigate failures

For the npm example, the Playwright CLI provides these commands. Use the corresponding runner from the other manager’s generated setup if applicable.

npx playwright test tests/smoke
npx playwright show-report

The configured trace keeps failure evidence. The trace viewer shows the actions and page state around a failure. Check whether the app broke, the test data changed or the server never started. Do not add retries merely to hide an unexplained failure.

Run the suite on the baseline and on the proposed change. In CI, install the project and Playwright browsers as documented, run the build and smoke checks, and retain failure artifacts with appropriate access. Review the generated workflow before enabling it. A smoke suite is a merge check, not continuous uptime monitoring.

For weekly upkeep, you can manually create a recurring dependency-review task with Denly’s task schedules after connecting a project and runner. Configure its instructions and review gates before enabling it. The public report form below creates a report; it does not create a schedule or a pull request.

Commands and product behavior on this page were checked against the vendor documentation linked here on 8 November 2026. Those products change their screens. If a label has moved, follow the linked page rather than a memory of this one.

Read next

How to update a Lovable project: GitHub sync and a one-time export · Lovable app not working after changes: recover and verify