Short answer
To test a Lovable app, run Lovable's security scan, then test the published lovable.app URL in a browser with a test account: sign-up, sign-in, every form and every page that should need a login. TestOptim AI does the browser part from the URL, including signed-in flows on any Lovable backend, and reports each bug with steps and a screenshot.
- Lovable apps run on a Supabase-based backend, so database access rules (RLS) are the first thing to check.
- On Lovable's built-in backend, the preview and published app share one database since 5 October 2026. Test data is real data.
- Lovable's own browser testing signs in only on its built-in backend; an outside agent can sign in on any.
On this page
How a Lovable app is built and hosted
Lovable builds a full-stack web app from chat. Projects created since May 2026 use TanStack Start with server-side rendering on Cloudflare Workers; older projects are React and Vite single-page apps. The backend is Lovable Cloud, which is Supabase underneath (Postgres, Auth, Storage and Edge Functions), or your own Supabase project.
Published apps live at your-app.lovable.app, or on a custom domain on paid plans, and are public by default. The editor preview needs a Lovable login, but a share-preview link opens without one until it expires. Either a published URL or a share-preview link works as the URL for TestOptim.
By default Lovable sets up sign-in with email and password, Google, and Sign in with Lovable. Phone codes, Apple, Microsoft and SSO are optional.
What Lovable already tests in your app
- Quick scan runs on every publish: missing RLS, policies that let everyone through, leaked-password protection turned off, critical dependency vulnerabilities and unauthenticated MCP servers.
- Deep scan runs on demand: an agent reviews access control, unauthenticated endpoints, injection, leaked secrets, payment tampering and auth bypass.
- Browser testing lets the agent click, fill forms and read console and network output in the preview at several screen sizes. It can sign in only when the app uses Lovable's built-in backend; on your own Supabase or another auth provider it tests logged-out pages only.
- Unit tests: Lovable can write Vitest tests for frontend rules you change.
Use all of them. What they leave open is testing the published app, signed in, on any backend, with negative and edge-case inputs, and repeating that after every prompt. That is what TestOptim adds.
Bugs to check in a Lovable app
- Database rows anyone can read or change. Lovable's own docs call missing RLS the most common way app data gets exposed. A 2025 scan of 1,645 Lovable apps found 170 with inadequate RLS (CVE-2025-48757, which Lovable disputes). TestOptim checks the browser side, such as pages and actions that work while logged out; use Lovable's scan for the database rules themselves.
- Sign-in works in the preview and fails when published. If the auth site URL or redirect URLs do not include your published domain, confirmation and sign-in links fail. Lovable updates them automatically only on its built-in backend, not on your own Supabase project.
- Test actions land in live data. Lovable retired its separate Test and Live databases on 5 October 2026, so on the built-in backend the preview, drafts, Lovable's browser tests and the published app share one database.
- Forms that accept anything. Generated forms often lack validation for empty, overlong or malformed input. TestOptim writes negative tests for every form it finds.
How to test a Lovable app with TestOptim AI
- Choose the URL: your
lovable.appaddress, your custom domain, or a share-preview link. Open the URL in a private browser window. If you see your app without signing in to the builder, TestOptim can reach it too. - Create a test account in the app with email and password, and confirm its email. If your app only offers Google sign-in, ask Lovable to add email sign-in; automated browsers often hit extra checks on Google's sign-in page.
- Create a TestOptim project with the URL and add the account as a credential profile.
- Explore and generate. Review the knowledge base: it should list your pages and flows. Then generate test cases.
- Run, then fix in Lovable. Paste an issue's steps and expected result into Lovable's chat and ask it to fix that behaviour. Mark the issue fixed in TestOptim to re-run its test.
- Keep it running. Lovable syncs to GitHub, so TestOptim can re-explore on every push to pick up new pages. Re-exploring does not run tests, so also schedule runs.
Because a Lovable app on the built-in backend shares one database between preview and live app, every record the agent creates is in your live data. Test before launch, or use a copy of the project with its own backend.
Frequently asked questions
Does Lovable test my app automatically?
Partly. Lovable runs a quick security scan on every publish, offers a deeper scan on demand, and its agent can test the preview in a browser. That browser testing signs in only on Lovable's built-in backend, and it tests the preview rather than the published app.
How do I check my Lovable app's Supabase RLS?
Run Lovable's security scan, which flags tables without RLS and policies that let everyone through, and fix each finding. Then test in a browser that pages and actions meant for signed-in users fail for a logged-out visitor; TestOptim tries those actions logged out automatically.
Why does sign-in work in the Lovable preview but not on my domain?
Usually because the auth site URL or redirect URLs do not include the published or custom domain. Lovable updates them on its built-in backend when you publish or connect a domain, but if you use your own Supabase project you must add them in Supabase yourself.
Will testing my Lovable app change its live data?
It can. Since 5 October 2026 a Lovable app on the built-in backend shares one database between preview and published app, so any record a tester or test agent creates is real. Test before launch, use a dedicated test account, or test a copy of the project with its own backend.
Can TestOptim test a Lovable app that uses Google sign-in?
Sign in with Google is hard for any automated browser, because Google often adds checks for unfamiliar devices. The reliable setup is to add email and password sign-in and create a test account with it, alongside Google sign-in for your users.
Can I test a Lovable app before publishing it?
Yes, with a share-preview link, which opens without a Lovable account. On Free and Pro plans the link expires after seven days, so create a new one if a scheduled run starts failing to load the app.
Sources
Platform facts were checked against these pages on 22 October 2026. Builders change quickly, so check them again before relying on a detail.
More Vibe-coded apps guides
- How to test a vibe-coded app before you launchHow to test a vibe-coded app from Lovable, Bolt, Replit, Base44 or v0: the bugs AI app builders leave, what their own checks miss, and a launch checklist.
- How to test a Bolt.new app before you launchHow to test a Bolt.new app: the localhost redirect, open database policies and missing env vars to check, and how to QA bolt.host.
- How to test a Replit app before you publishHow to test a Replit app: secrets and databases that differ in production, Replit Auth sign-in, what Replit App Testing covers, and how to QA replit.app.
- How to test a Base44 app before you launchHow to test a Base44 app: what the Testing Agent and Security Scan cover, why sign-in can only be tested once published, and how to QA base44.app.
- How to test a v0 app before it reaches productionHow to test a v0 app on Vercel: protected preview deployments, NEXT_PUBLIC_ secrets, env vars that differ by environment, and how to QA production.