Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/J0S3-LEON/pf_pruebasAseguramientoCalid_SDD/llms.txt

Use this file to discover all available pages before exploring further.

MindFlow’s test suites are organized in a Jest multi-project monorepo. The root jest.config.js delegates to per-workspace configurations — apps/backend, apps/frontend, and packages/shared — so you can run everything at once from the repo root, or target a single workspace for faster feedback during development. The sections below cover every command you need, from a full suite run to a single spec file.

​
All test commands

# Runs all tests across all workspaces via the root Jest config
npm test

​
Test file patterns

Jest discovers tests by filename pattern. Each category uses a distinct suffix so you can target or exclude entire categories with --testPathPattern.
CategoryFile patternDescription
Unit tests*.service.spec.ts, *.controller.spec.tsSingle service or controller in isolation with mocked dependencies
Property-based tests*.property.spec.tsfast-check properties run with numRuns ≥ 5 (100 for non-async)
Smoke tests*.smoke.spec.tsStatic config validation — Dockerfile, Prisma schema, compose.yml
Integration testsintegration/*.latency.spec.tsDB writer latency over 10 mocked writes; validates Prisma pool config statically

​
Running a single spec file

Target any spec file directly with npx jest and its workspace-relative path: 
npx jest apps/backend/src/auth/__tests__/auth.property.spec.ts

npx jest apps/backend/src/tasks/__tests__/task.service.spec.ts

npx jest apps/backend/src/__tests__/api-gateway.property.spec.ts

​
Running tests by pattern

Use --testPathPattern to select all files whose path matches a substring: 
# Run all property-based tests
npx jest --testPathPattern="property"

# Run all smoke tests
npx jest --testPathPattern="smoke"

# Run all integration/latency tests
npx jest --testPathPattern="latency"

# Run all auth-related tests (unit + property)
npx jest --testPathPattern="auth"

​
Environment setup for integration tests

The latency spec (__tests__/integration/db-writer.latency.spec.ts) uses a mocked PrismaService — no real PostgreSQL connection is required. If DATABASE_URL is available in the environment the Prisma pool config test will read it directly; if it is absent, the test falls back to validating the documented reference URL string.
npx jest --testPathPattern="latency"
To also validate pool settings against a live database URL, set DATABASE_URL before running:
export DATABASE_URL="postgresql://mindflow:password@localhost:5432/mindflow_dev?connection_limit=10&pool_timeout=20"
npx jest --testPathPattern="latency"

​
Smoke tests are DB-independent

Smoke tests validate static configuration artifacts only — they do not connect to PostgreSQL, spin up Docker containers, or load environment variables. You can run them on any machine, including a bare CI runner with no infrastructure:
npx jest --testPathPattern="smoke"
Smoke tests check: compose.yml service definitions, absence of hardcoded secrets in the backend container config, Prisma schema pool settings (connection_limit=10, pool_timeout), and the mindflow_pgdata named volume declaration.

​
Parallel vs. sequential execution

All backend tests — including the latency integration tests — use in-memory PrismaService mocks and are safe to run in parallel (the default Jest behavior). Use --runInBand only if you need fully deterministic, reproducible CI output or are debugging a test ordering issue.
npm test --workspace @mindflow/backend -- --runInBand
Unit, PBT, smoke, and integration tests never open a real database connection, so parallel execution does not risk connection pool exhaustion.

​
What a passing PBT run looks like

When all properties pass, fast-check is silent in the Jest output — you see the standard green checkmark for each it block. When a property fails, fast-check prints a detailed report before throwing: 
Property failed after 12 tests
{ seed: 1837462910, path: "11:2:0", endOnFailure: true }
Counterexample: [{ id: "00000000-0000-0000-0000-000000000000", score: 6, ... }]
Shrunk 3 time(s)
Got error: expect(received).toEqual(expected)
The output tells you:
  • seed — use this value with { seed: 1837462910 } to reproduce the exact same sequence
  • path — the position in fast-check’s internal shrink tree where the minimal counterexample was found
  • Counterexample — the smallest input that still triggers the failure (fast-check shrinks automatically)
  • Shrunk N time(s) — how many shrink steps were taken to reach the minimal example

​
Latency test behavior

Latency tests (__tests__/integration/db-writer.latency.spec.ts) measure the time for 10 consecutive DBWriterService.writeSession() calls through an in-memory mocked PrismaService that resolves immediately. Because there is no real I/O, average latency will be close to 0 ms — well under the 3 000 ms threshold required by Requirement 3.3. The purpose is to verify that the DBWriterService code path introduces no inherent latency overhead and that the service returns structurally correct results for all 10 calls.The same spec also validates Prisma connection pool configuration statically (pool connection_limit=10, pool_timeout=20), without opening any real database connection.

Build docs developers (and LLMs) love

Get started for freeTalk to us