# Phase 16 acceptance testing

Run acceptance tests against a disposable copy of the production database and uploads. Never use the first test run against the live database.

## Automated Windows test

From PowerShell in the project root:

```powershell
Set-ExecutionPolicy -Scope Process Bypass
.\scripts\acceptance-test.ps1
```

The runner stops at the first failure. After the legacy audit reports that migration is safe, it runs the conversion's additive migrations before checking migration status. Preserve its console output when requesting support.

The runners recreate Laravel's required writable runtime directories before clearing caches. The release also includes an explicit `config/view.php`, so extracted ZIP installations do not depend on empty-directory preservation.

## Installer acceptance

1. Back up and import `modernstore.sql` into a new database.
2. Copy `.env.example` to `.env`, configure `APP_KEY`, use `APP_ENV=local`, and set `INSTALLER_ENABLED=true`.
3. Open `/install` in a private browser window.
4. Confirm all requirements pass and deliberately try one incorrect database password; the page must reject it without displaying the password.
5. Connect the imported database and run the audit/migration step. Confirm its report says `safe_to_migrate: true`.
6. Create the administrator, save company details, and verify the licensing endpoint.
7. Finish installation. Confirm `/install` redirects away and `storage/app/private/installed` exists.
8. Sign in with the new administrator and confirm the admin dashboard opens.

## Business acceptance matrix

| Area | Required acceptance |
| --- | --- |
| Accounts | Register, verify email, sign in/out, reset password, administrator and seller authorization |
| Catalogue | Categories, product search/filter, product details, media, comments, reviews and wishlist |
| Seller | Create/edit product, inventory, variations, coupons, shipping, orders, payouts and affiliate settings |
| Checkout | Guest/member cart, address, coupon, shipping/tax totals and order creation |
| Payments | Successful, failed and duplicate callbacks for each enabled gateway; never mark paid without a verified callback |
| Fulfilment | Seller/admin order progression, customer history, invoice and notifications |
| Digital sales | Authorized download works; anonymous, expired and unrelated-user download attempts fail |
| Refunds | Request, seller/admin response, approval/rejection and financial status consistency |
| Content | Pages, blog, knowledge base, contact, newsletter, sitemap, feed and localized routes |
| Support | Member and guest tickets, token protection, replies and notifications |
| Affiliate | Referral attribution, earnings, dashboard totals and payout data |
| Licensing | Valid activation, cached validation, explicit revocation and temporary server outage grace |

## Production cutover

1. Take a fresh database and uploads backup and place the old application in maintenance mode.
2. Deploy the tested archive to a new release directory and point the document root to `public/`.
3. Use production `.env` values with HTTPS, `APP_DEBUG=false`, and file-backed session/cache for the first launch.
4. Import the final database, run `php artisan webmarket:legacy-audit`, `php artisan migrate --force`, and `php artisan webmarket:legacy-integrity`.
5. Import/verify uploads, run `php artisan storage:link`, then finish the installer if it was not completed in staging.
6. Set `INSTALLER_ENABLED=false`; run `php artisan optimize` and `php artisan webmarket:deployment-check`.
7. Configure the scheduler every minute and a supervised queue worker or cPanel cron-compatible queue strategy.
8. Test one low-value real payment and verified webhook before announcing launch.
9. Keep the previous release and database backup available for rollback until post-launch checks pass.

Do not launch while any automated check or required matrix item is failing.