Experimental. Automated testing is new and still evolving. The behavior described here works
today, but details may change. If anything looks off, contact us. How It Works
Each test walks through a critical workflow the way a customer would—“add two items to the cart, check out, confirm the order shows up”—and checks the result. If the workflow breaks, the test fails.
Tests run in a safe, isolated copy of your app: a private in-memory database and stand-ins for email, payments, and sign-in. Running tests never touches real customer data, never sends real emails, and never charges real cards. That’s why you can run them as often as you like.
The Tests Tab
To see and run your tests:
Open your app
Open your app in Stardeck and click the Cloud button in the top-right.
Go to the Tests tab
Under Observability, open
Tests. Run the suite
Click Run all to run everything, or Run next to a single workflow to run just that one.
Running tests needs your app’s workspace to be open and started. If it isn’t, you’ll see a prompt
to open the project first.
Tests Run on Every Deploy
When you publish or deploy a preview, Stardeck runs the test suite first. If a critical workflow is failing, the deploy is blocked—the broken version never goes live. The failure shows up on the deployment with the details, and the agent can pick it up to fix.
If a project has no tests yet, deploys proceed normally—the gate only blocks on an actual failing test.
Turning the gate on or off
The deploy-time test gate is on by default. You can turn it off from the Production or Preview settings tab, under Run tests before deploying. With it off, deploys skip the test step (you can still run tests anytime from the Tests tab).
Leave the gate on once you have tests for your important workflows—it’s the cheapest insurance
against shipping a broken checkout or booking flow.
Adding or Changing Tests
Just ask the agent, in plain English, to cover the workflows that matter. For example:
Add a test for the checkout flow: adding items, paying with a test card, and seeing the order in admin
Write a test that makes sure two people can't book the same time slot
Cover the inventory workflow—placing an order should reduce stock, and you can't order more than is in stock
Describe the workflow the way you’d describe it to a new employee—the steps a customer takes and
what should happen. That’s exactly what makes a good test.
Running Tests Locally
If you work on your app locally (for example with Claude Code), the test suite is a standard Vitest project. From your app directory:
The same hermetic database and service stand-ins are used locally, so local runs are safe and need no real credentials. See Local Development for connecting your local environment.
Common Questions
Do tests cost anything or affect my customers?
No. Tests run against an isolated in-memory copy of your app—no real data, emails, payments, or customer impact. They use a little of your app’s workspace compute while running, nothing more.
My deploy was blocked by a failing test. What do I do?
Open the failed deployment to see which workflow failed and why, then ask the agent to fix it (or use Fix with Agent). Once the test passes, deploy again. If you need to ship urgently, you can turn off the deploy gate in the Production/Preview settings—but fixing the failing workflow is usually the safer choice.
My app doesn’t have any tests yet.
That’s fine—nothing is blocked. Ask the agent to add tests for your most important workflow to get started.
Can I test a single workflow without running everything?
Yes. In the Tests tab, click Run next to any individual workflow.
