How to test a Lovable project before publishing

Start with the rules that protect your business

Pick the workflows whose failure would cost your customers time, access or trust. Write an outcome you can verify, instead of a vague instruction such as “test the dashboard.”

Apply the same approach to workspace isolation, invitations, exports and record updates. You do not need hundreds of ideas to start: choose the few rules that would make a release unacceptable if they broke.

Use a safe, repeatable test environment

Use a separate test environment with test accounts and disposable data. Confirm that it uses the intended database and services before running actions that create, update or delete records.

• Create an owner, an editor and a viewer account.
• Create two workspaces with different members and documents.
• Record the version, configuration and starting data for the test.
• Reset the data between runs so yesterday’s results cannot change today’s outcome.

A successful result on one version does not verify a later change. Repeat the checks against the version you intend to publish.

Check the boundary, not just the happy path

A useful scenario identifies the role, starting state, action and observable result. Include a permitted action, a blocked action and a realistic interruption.

For permissions, a hidden button is not sufficient evidence. Check the request and the data boundary too: the backend must reject an operation the user is not allowed to perform. If your system uses Supabase, that includes the relevant access policies.

Check the saved state after the interaction

A success message only proves that the interface displayed a message. Reload the page, sign in with the relevant account and inspect the saved result. For a blocked action, verify both the rejection and the absence of unintended changes.

Capture enough evidence to repeat a failure: the tested version, account role, starting data, steps, expected result and observed result. A screenshot helps explain the interface; the request response and resulting state help explain what actually happened.

Keep the scenario for the next change

After a fix, rerun the failing scenario and nearby workflows. A corrected deletion rule should still let an authorized editor make a legitimate change. Keep the scenario as a regression check so a later edit can be compared with the same expectation.

Lovable provides browser, frontend and backend testing tools. Its testing documentation explains when to use them. The question for a release is whether the checks you ran cover the business rules affected by this particular change.