# Testing

## Posture

**No formal test infrastructure.** No PHPUnit, no Pest, no `tests/` or `spec/` directories, no `phpunit.xml`, no `composer.json`. No CI pipeline (no `.github/workflows`).

## What exists

Manual debug scripts under [tmp/](tmp/) — developer-run, not automated:

| File | Purpose |
|---|---|
| `tmp/debug_clients.php` | Client sync verification |
| `tmp/debug_clients_remote.php`, `debug_clients_remote2.php` | Remote API checks |
| `tmp/debug_dup_products.php` | Duplicate product detection (currently uncommitted) |
| `tmp/debug_eligible_remote.php` | Eligibility checks |
| `tmp/debug_products_urls.php` | URL fetch verification |
| `tmp/campaign_alerts_debug.log` | Output log from alerts run |
| `tmp/meta_active_last30d.json`, `tmp/products_data_save.txt` | Test data snapshots |

These scripts contain **live database credentials** — see [concerns.md](concerns.md) for the security implication.

## Implicit "tests"

- `cron_sync_status` table acts as production-time integration check (phase progression).
- `logs` table provides audit trail for after-the-fact debugging.
- Settings keys `*_last_error` / `*_last_error_at` capture last failure per integration.

## Recommendations (if testing is introduced)

1. Adopt PHPUnit via Composer (also fixes the lack of dependency management).
2. Start with **factory** layer — it's the most testable (pure DB queries given a fixture DB).
3. Service layer needs HTTP client abstraction before the cURL calls can be tested without hitting live APIs.
4. Migrations are already partly idempotent — a CI job that runs `php install.php` against a scratch DB would be cheap insurance.
5. Move `tmp/debug_*.php` content into proper integration tests; delete the scripts.