adsPRO/.paul/codebase/testing.md

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/ — 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 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.