Testing

The repository uses the built-in Node.js test runner. Unit tests live in test/ and integration tests in test/integration/. Most tests run without external services by stubbing the clients they exercise. Integration tests opt in through environment flags so a normal test run skips anything that needs live infrastructure.

Running Tests

Run every unit test file:

pnpm test

Run one focused file while working on a change:

pnpm exec node --test --test-force-exit test/tracking-service.test.js

The full integration set is collected in test:integration. Each file still checks its own gate, so you can also run a single integration file with its flag, for example ACCOUNT_DELETION_INTEGRATION=1 for the account deletion suite.

Fixture Isolation

Integration tests must never write to a shared development database. Each suite builds its own throwaway scope and removes it in a finally block, even when an assertion fails.

The account deletion suite applies this to every store it touches:

• MongoDB: the process connects to the configured server but swaps into a unique managani_deletion_test_<uuid> database that is dropped when the test ends.
• Typesense: the suite creates collections named for the test host and deletes them afterwards.
• ClickHouse: the suite works only inside a guarded fixture database, described next.

ClickHouse Account Deletion Fixture

The account deletion worker removes analytics rows with a real ALTER TABLE ... DELETE mutation. The suite therefore needs a live ClickHouse connection, but the runtime application identity is intentionally limited to SELECT, INSERT, and ALTER DELETE on the tracking table of the product database. It cannot create or drop anything, and tests must not widen it.

Instead, run the test process with the standard CLICKHOUSE_* environment overrides pointed at a separate operator identity:

Variable	Value for the test run
CLICKHOUSE_URL	ClickHouse HTTP endpoint
CLICKHOUSE_DATABASE	managani_deletion_test_<uuid32>, unique per run
CLICKHOUSE_USER	Operator identity with fixture DDL rights
CLICKHOUSE_PASSWORD	Operator password

The suite refuses to start its ClickHouse work unless CLICKHOUSE_DATABASE matches managani_deletion_test_ followed by 32 lowercase hex characters. This check runs before the first fixture statement, so a run with the development default (managani) fails immediately instead of touching the tracking data. The test also confirms that the connection resolves unqualified table names to the fixture database.

The operator identity needs these grants, and nothing else:

• CREATE DATABASE so the suite can create its fixture database when it does not exist yet.
• On the fixture database: CREATE TABLE, SELECT, INSERT, ALTER DELETE, and DROP DATABASE.

The suite first creates its database through a bootstrap connection to default, then verifies that its working connection selects that database. It creates a unique deletion_fixture_<host> table inside it and drops the owned database in cleanup, even when later setup fails. A name that already exists is rejected and left untouched. Do not precreate the database; use a fresh name for every run.

Passwords stay out of the repository. Pass credentials to the test process through the environment, never through configuration files, and keep the runtime managani_user grants unchanged.