JOB-EASY

Testing & Quality Assurance

How Job-Easy enforces correctness through static boundaries and schema-bound integration harnesses.

The platform ensures correctness through a strict combination of static analysis (TypeScript + ESLint), extremely fast unit tests, and database-backed workflows that protect critical architectural invariants.

The Testing Pyramid

1

Static Analysis

TypeScript strict mode and ESLint boundary rules instantly catch architecture violations.

658

Unit Tests

Pure logic testing (mappers, schemas, parsers) using the Node.js native test runner.

14

Integration Harnesses

Database-backed workflows guaranteeing invariants like GDPR deletion and queue claiming.

Unit Testing (node:test)

We use the native Node.js test runner (node:test) instead of Jest or Vitest. This results in zero configuration, instant execution, and no dependency overhead. Tests are strictly colocated in __tests__ directories within each feature slice.

No Database in Unit Tests

Unit tests never touch the database. If a test requires Prisma, it is an integration test and belongs in the isolated /tests/integration directory at the root, ensuring the unit test suite remains blisteringly fast.

Schema-Bound Integration Testing

Integration tests run against a real, isolated PostgreSQL database container. They don't just test basic CRUD operations; they enforce the system's hardest architectural invariants against future regression.

  • GDPR Deletion Exhaustiveness: A test actively reflects on the Prisma schema metadata. If a developer adds a new table with a relation to User but forgets to add it to the accountDeletion.workflow.ts cascade transaction, the test suite instantly fails.
  • Cron Job Drift: A test enforces that the internal constants/jobs.ts registry perfectly mirrors the deployment vercel.json file, guaranteeing that a new cron job is never deployed without a backing handler, or vice-versa.
  • Mail Queue Concurrency: Tests simulate concurrent cron invocations to guarantee that the FOR UPDATE SKIP LOCKED queue mechanism never double-sends a transactional email.

ESLint Boundary Enforcement

The 5-tier architecture is actively enforced by eslint-plugin-import zone rules. For example, if a developer in src/components (Tier 3) attempts to import directly from a database repository in src/features (Tier 1), the build fails. This prevents the codebase from deteriorating into a big ball of mud.

PreviousProject ChallengesNextDeveloper Setup