Testing and verification

Define success before the change

Give Amazi an observable acceptance criterion. “Add a contact form” is less specific than “save a valid request, show confirmation after saving, and let staff see the new request.”

Choose the page, role, data state, action, and expected result. For bugs, include reproducible steps and what must remain unchanged.

Understand different checks

• Formatting, lint, and type checks find particular source-code problems.
• Automated tests verify the cases they actually cover.
• A successful build shows that the application can be built with that configuration.
• A health response shows that a specific endpoint answered.
• Browser verification checks the rendered interaction and visible result.
• Production verification checks the activated release at its public address.

These checks complement one another. A successful build or HTTP 200 does not prove that a form saves, a protected route enforces permissions, or the public preview is reachable.

Amazi treats tasks without code writing or changes, and code changes totaling roughly 100 lines or fewer, as simple. It estimates the code it expects to add, change, or remove itself; you do not need to count lines or classify the task. The size of the existing project does not determine the amount of work. For these tasks, formatting, code review, lint, type checks, writing or running tests, and builds are all optional; Amazi chooses useful steps and can complete the task without them. If you need a particular check, explicitly ask for it. Larger code changes require relevant verification. A check that was not run must not be reported as passed.

Amazi can continue independent work while a build or check runs, then read its result. For longer project commands it can allow up to five minutes. A started command is not a successful check: wait for the actual result before treating it as verified.

Review a complete user journey

Open the affected page in Preview. Check the normal path and a relevant failure case. For a form, try valid input, invalid input, and the result after reloading. For navigation, check direct page URLs and browser back/forward behavior rather than only clicking between views.

Review the phone layout as well as desktop. Confirm that controls remain reachable and content does not overflow. For signed-in workflows, verify the appropriate role using Application users and authentication.

Use synthetic data. Preview can write to the same managed database as production, so test actions are not automatically harmless.

Before publishing

Confirm which source version will be released, that required connections and environment values are configured, and that the affected workflows passed their intended checks. Publishing code and changing database state are separate concerns.

Ask Amazi to report what was actually checked and what remains unverified. Do not interpret “implemented” as “published,” or “published” as “every workflow verified.”

After publication, open the production address and repeat a focused smoke test of the changed behavior. If deployment fails, inspect the production diagnostic before retrying. See Publishing and domains.

When a check is blocked

Record the exact blocker and the affected scenario. If Preview returns a gateway error, use Preview troubleshooting. An unavailable preview should be reported as an unverified browser result, not disguised as a passing test.