Skip to main content

Test coverage

Every Certeasy release ships only after the full automated test suite passes against the targeted database backends. This page lists the suites that compose the gate, what each one verifies, and the headline counts at the time of writing.

Headline numbers​

CategoryTestsWhat it verifies
Unit (TU)474Pure logic: configuration parsing, policy resolution, JWS signing primitives, DNS scope matching, CSR validation, crypto helpers, rate-limit decision tables, audit-line encoding. No I/O, no database.
Integration (IT)63Real database (SQLite, PostgreSQL, SQL Server), real audit file on disk, real PKI request store, full ACME handler stack wired against the storage layer. Each test runs against every supported database backend.
End-to-end (E2E)68The full Certeasy binary running as a subprocess. Two flavours: (1) CLI black-box — every subcommand (serve, license, backup, audit verify), exit codes, error messages. (2) ACME protocol — real third-party clients (lego, certbot, acme.sh) plus a RFC-strict native client driving certificate issuance, renewal, revocation, account lifecycle, key rollover, and the full error/security path.
Total605

Numbers are refreshed at every release. The most recent count above reflects the v0.9 line.

What is covered, by area​

ACME protocol (RFC 8555 + RFC 9773)​

  • Account: create, lookup-by-key, contact update, deactivate, key rollover (including the 409 Conflict path when rolling to an already-used key).
  • Order: create, get, finalize, state machine transitions, expiry.
  • Authorization + challenges: HTTP-01, DNS-01, TLS-ALPN-01 — happy path and every documented failure mode.
  • Wildcards: pure *.zone and mixed zone + *.zone in a single order.
  • Renewal information (ARI): suggested window, Retry-After, revoked-cert collapse to immediate renewal.
  • Revocation: client-signed and account-key-signed paths, double-revoke rejection.
  • URL and header conformance: every endpoint where RFC 8555 requires a Location header is asserted on the wire.

ACME client interoperability​

E2E suite runs the full happy-path issuance against:

  • lego — HTTP-01, DNS-01, TLS-ALPN-01.
  • certbot — HTTP-01, DNS-01.
  • acme.sh — HTTP-01, DNS-01, TLS-ALPN-01.
  • A built-in RFC-strict native client (golang.org/x/crypto/acme) for paths the third-party CLIs do not exercise: error-path, security probes, account lifecycle ops, RFC URL/header conformance.

Database support​

The integration suite runs the same test set against every supported backend:

  • SQLite — always.
  • PostgreSQL — when configured in the CI environment.
  • SQL Server — when configured in the CI environment.

Schema migrations, concurrent-writer behaviour (serialisable retry), and dialect-specific edge cases (UUID handling, NULL semantics in unique indexes, cascade chain restrictions on SQL Server) are all covered.

Rate limiting​

Dedicated suite (7 tests) under a tight rate-limit profile, covering global denial, account-creation throttling, order-creation throttling, duplicate-certificate refusal, failed-validation back-off, and the pending-authorization cap.

Audit log​

  • Round-trip write + verify on every supported database backend.
  • HMAC chain anchoring on installation_id.
  • Recovery across process restart, including rotated files.
  • Tampering detection (line removed, line modified, MAC altered, wrong installation_id).
  • Every protocol event (account create / key change / deactivate, order create / finalize / invalid, authorization & challenge validate, certificate issue / revoke, rate-limit deny, license deny) is asserted to fire exactly once at the right point in the request lifecycle.

License enforcement​

  • Boot-strict refusal (no license, expired license, wrong environment).
  • Runtime per-order enforcement (max_managed_servers, max_cas, allowed_dbs, max_managed_servers=0).
  • Renewal escape hatch (an order for a domain already covered by an active certificate is not counted against the cap).
  • Acknowledgement path for boot-degraded states.

CLI​

Every subcommand and flag is exercised in the E2E suite: argument validation, exit codes, error messages on missing file / bad format / incompatible flag combinations, help output for every command level.

Backup & restore​

  • SQLite snapshot round-trip with schema verification.
  • Integrity check (quick and full).
  • Refusal to overwrite an existing target.
  • Verify against a corrupted file / missing tables / wrong driver.

Cross-platform​

The suite is run on Linux for every release. The protocol suite is additionally run on Windows when an ADCS lab is available (the ADCS backend variant is gated on a Windows host with certreq.exe).

How the categories are defined​

Classification is purely based on the file path of the test, so the numbers are reproducible without judgement calls:

  • End-to-end (E2E) — tests that run the Certeasy binary as a subprocess and assert on the wire or the CLI output.
  • Integration (IT) — tests that hit a real database, write a real audit file to disk, or wire the full handler stack against a real storage backend.
  • Unit (TU) — every other test: pure-function logic with no I/O.

A test that touches both a database and a real subprocess counts as E2E (the more demanding category wins).

Where the numbers come from​

The full suite is launched from the repository root with a single script that records pass/fail/skip per module and writes per-module logs for diagnostics. The headline numbers above are produced by enumerating go test -list per module and classifying each test by its package path.