Where danwo runs
Which should I use?
A few questions to find your setup, and which one to use for each purpose.
Most teams use more than one setup: local runs on every pull request, staging before a release, and a smoke test after each deploy. Answer these questions to find the setup for what you're doing now.
Find your setup
Is it production?
Use a smoke test on production: a few short checks, a test account, no matrix.
Is it a deployed environment, such as staging?
Use staging, with your providers' real test accounts.
Can you start the backend on your machine?
- One app serves pages and API (Next.js, Remix, Nuxt, SvelteKit): use a full-stack app.
- Separate frontend and API: use frontend and backend.
You can only run the frontend?
Use frontend only, against a remote API. Emulate only what the browser alone uses.
By purpose
| Purpose | Setup | Why |
|---|---|---|
| Every pull request, in CI | Full-stack app or frontend and backend | Everything emulated and breakable, the same result every time. |
| Finding the bugs only failures cause | the same, with danwo matrix | The matrix needs the calls to go through danwo. |
| Before a release | Staging, with real sandboxes | Checks the real deployment and real provider configuration. |
| After a deploy | Production, smoke tests only | Confirms the live site works, without touching real data. |
| A frontend team without a runnable backend | Frontend only | Covers the browser's side today. |
For frontend teams, an emulator of your own API built from its OpenAPI description is planned. It isn't built yet.