Test strategy

Purpose

Describe what automated testing means for leekimerp on Frappe / ERPNext: layers of the pyramid, how bench run-tests fits, and coverage as an org policy — not a hard number mandated by this repo. Operational evidence lives in Test evidence & CI.

Test pyramid (intent)

Layer	Typical scope in Frappe apps	Notes
Unit	Pure Python helpers, validation logic isolated from DB where feasible	Fast; prefer deterministic inputs.
Integration	DocType lifecycle, `@frappe.whitelist` methods with test site, `doc_events` / scheduler behavior	Uses Bench site; dominant layer for ERP extensions.
E2E / manual	Full flows: payroll run, billing → Xero, webhooks from provider sandboxes	Capture in UAT checklists; align with tutorials.

Exact test modules are defined in app hooks.py and team convention — this document does not replace pytest discovery configuration.

Commands and evidence

From Bench root with site context:

bench --site <site> run-tests --app leekimerp

Handover evidence: stdout/stderr log, date, bench version output, git SHA — see Test evidence & CI.

Coverage policy (organization standard)

This repository does not enforce a global coverage percentage in CI by default. Recommended policy:

Area	Expectation
Critical paths	Payment-adjacent code, payroll hooks, guest webhooks (`allow_guest=True`), and idempotency — should have automated tests before large refactors.
New whitelisted APIs	Add or extend tests when behavior is non-trivial; cross-check API inventory.
Coverage reports	If enabled (`coverage` / CI artifact), archive HTML or summary with release — optional column in Test evidence.

Set concrete thresholds (e.g. minimum % on leekimerp/api/) in your pipeline configuration; link that policy from your internal wiki into release notes.

Documentation site (`docs/`)

The Astro site has its own CI (see Test evidence & CI): generate:doctypes, inventory CSV checks, npm run build. That is not Python coverage — treat it as docs quality gates.