Built with Chinaski

Running the Test Suite

Chinaski ships its own test harness: t/ plus the shared bootstrap t/helper.pl. Roughly 120 test files, all runnable with one command.

In one line

CHINASKI_SECRET=ci-test-secret prove -lr t/

That’s the same invocation the project’s CI uses (prove -lr t/ on every push and every PR to main), with the secret set in CI’s environment. Individual files run on demand: perl t/pages.t or prove -l t/pages.t.

What helper.pl provides

Test files bootstrap without boilerplate:

  • setup_test_env sets the session secret and MOJO_MODE=test, builds a fresh SQLite temp database from the real schema.sql, points CHINASKI_DB at it, and sets a per-run documents directory so scratch files never collide between users or runs. It also pre-creates the (gitignored) build output directory so the /health writable-output check doesn’t fail as a false positive on a fresh checkout.
  • Cleanup is registered — an END block removes the temp DB’s WAL sidecars and the per-run docs directory. Both used to accumulate across runs on the project’s own machine before that fix, so the cleanup is load-bearing.
  • Seed data — two accounts (admin/admin123 with the admin role, editor/editor123 with the editor role) against a two-language site (en, es), bcrypt-hashed at setup time.
  • Login helpers perform the whole sign-in flow — fetch the login page, scrape the CSRF token, post credentials, land in /admin.
  • The app under test is the production cms.pl itself loaded into a Test::Mojo harness (with the session cookie’s Secure flag disabled for the non-HTTPS test loop); the suite always tests the shipped code, never a stub.

Getting access in tests

login_admin and login_editor handle the details including CSRF-token scraping from the rendered login page. Tests needing finer control can hit routes directly with the token helpers.

Environment prerequisites

  • The same dependency set as the app (Perl 5.26+, Mojolicious, DBI/DBD::SQLite, Template, Imager, DateTime, Crypt modules, sqlite3 for DB setup).
  • The CI workflow doubles as documentation of the host-side provisioning recipe (system libraries plus a cpanm install list), and runs on a self-hosted runner colocated with the deployment host — dependencies are provisioned once system-wide, not per run.

The separately tested MCP server

chinaski-mcp/mcp.t is the MCP server’s own suite. It sets the required CHINASKI_API_URL/CHINASKI_API_KEY per test (the server refuses to start without both) and tests the API-facing protocol behavior in isolation.

Conventions worth knowing

  • Test files that shell out to the builder set CHINASKI_TEST=1, because the builder otherwise refuses to run as root.
  • Numeric-prefixed files (00-compile.t, 01-schema.t, 02-media-sniff.t, 03-util.t, 04-webhook.t) act as pre-flight checks — a broken build or a schema change surfaces there first in a prove -lr t/ pass before any feature test would.
  • The suite is developed for Linux (the CI runner is Linux; CI runs the same toolchain as production deployments).