Developer reference
What to verify
A practical acceptance map for source, services, database, providers, browser and documentation.
Choose cases by the failure they prevent. A large passing test count is less useful than evidence that the changed contract behaves correctly.
Layer map
| Layer | Useful acceptance |
|---|---|
| Pure domain | Precision, currencies, Cairo dates, classifications and command validation. |
| Service/API | Ownership, scopes, safe errors, exact retry intent and unavailable reads. |
| Database | Balanced entries, permissions, atomicity and concurrency. |
| Provider | Actual session verification/revocation and mail transport when needed. |
| Browser | Real signup, account/balance recovery, recording, imports and cache retirement. |
| Documentation | Accurate steps, stable links, navigation, compiled pages and search. |
| Hosted release | Canonical origins, redirects, runtime configuration and scheduled work. |
First-use example
Account creation success followed by balance failure should keep the same account recoverable. A retry must not create a duplicate. Completion requires confirmed balance basis and a fresh owned read. Zero is valid; unknown does not complete financial setup.
Import example
Upload and preview must not record money. Explicit start authorizes the reviewed version. Continue resumes the same job. Undo refuses changed or linked work rather than removing unrelated history.
Privacy example
A delayed previous-account response and a restored Back page cannot reveal retired private content. Test portal content as well as the main page.
Test names and counts change with source. Verify the revision being released instead of reusing a historical count. Continue with runner commands.