Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/bloom-housing/bloom/llms.txt

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

Bloom has test coverage across the full stack. The backend supports two distinct testing modes, and each frontend site has both Cypress E2E and Jest unit test suites.

​
Backend tests

The backend (api/) supports two kinds of tests:

Unit tests

Mock the Prisma service and test business logic in isolation — no database required. Files live under test/unit/ with the .spec.ts extension.

Integration tests

Use a real database and test the full request/response cycle through the controller endpoints. Files live under test/integration/ with the .e2e-spec.ts extension.

​
Running unit tests

Unit tests require two environment variables. Create a .env file in the api/ directory before running: 
echo 'TIME_ZONE=America/Los_Angeles' > .env
echo 'CLOUDINARY_CLOUD_NAME=exygy' >> .env
Then run the tests from the api/ directory: 
yarn test

​
Running integration tests

From the api/ directory: 
yarn test:e2e
Integration tests require a running Postgres database. The database should start empty and will be cleaned up after the suite completes.

​
Running with code coverage

yarn test:cov
Coverage is calculated across both the unit and integration test runs. Coverage benchmarks must be met for CI to pass — a PR that drops below the configured threshold will fail the coverage check.

​
Frontend tests

Each frontend site (sites/public and sites/partners) has two layers of tests.
Run these commands from the sites/public/ directory.
CommandDescription
yarn testCypress E2E tests (requires the app to be running)
yarn test:headlessCypress E2E tests in headless mode
yarn test:unitJest unit and integration tests
yarn test:unit:coverageJest unit and integration tests with coverage
Cypress E2E tests require the application to already be running. Start the full stack with yarn dev:all from the repo root before running yarn test in a site directory.

​
Root-level test commands

The root package.json provides convenience scripts to run tests for any part of the stack without needing to cd into subdirectories.
ScriptWhat it runs
yarn test:backend:newAPI unit tests (api/ directory)
yarn test:backend:new:e2eAPI integration tests
yarn test:backend:new:covAPI tests with coverage
yarn test:app:publicPublic site Cypress E2E tests
yarn test:app:partnersPartners site Cypress E2E tests
yarn test:app:public:unitPublic site Jest tests with coverage
yarn test:app:partners:unitPartners site Jest tests with coverage
yarn test:shared-helpersShared-helpers package tests

​
Writing tests

​
Unit test conventions

  • Mock the PrismaService — unit tests must not touch the database.
  • Test service functions directly rather than going through the HTTP layer.
  • Cover edge cases and error conditions, not just the happy path.
  • File extension: .spec.ts, located under test/unit/.
// Example: mocking PrismaService in a unit test
jest.mock('../src/services/prisma.service');

describe('ListingService', () => {
  it('throws NotFoundException when listing does not exist', async () => {
    prismaService.listings.findUnique.mockResolvedValue(null)
    await expect(service.findOne('nonexistent-id')).rejects.toThrow(NotFoundException)
  })
})

​
Integration test conventions

  • Start with an empty database — do not rely on pre-seeded data.
  • Clean up all created records after each test or test suite completes.
  • Mock as little as possible; the point is to verify real database interactions.
  • File extension: .e2e-spec.ts, located under test/integration/.
// Example: cleanup pattern in an integration test
afterEach(async () => {
  await prismaService.listings.deleteMany()
  await prismaService.jurisdictions.deleteMany()
})

​
CI test suite

Every pull request triggers the full test suite via GitHub Actions:
1

API unit tests

Runs all .spec.ts files under test/unit/.
2

API integration tests

Runs all .e2e-spec.ts files under test/integration/ against a real database.
3

Public site unit/integration tests

Runs Jest tests for sites/public.
4

Public site Cypress tests

Runs the full Cypress E2E suite for the public applicant-facing site.
5

Partners site unit/integration tests

Runs Jest tests for sites/partners.
6

Partners site Cypress tests

Runs the full Cypress E2E suite for the partners portal.
No PR that introduces failures in existing tests will be accepted. All coverage benchmarks must be met.
To investigate Cypress failures in more detail, set record: true in the relevant workflow file under .github/workflows/. Test videos will be recorded and available in Cypress Cloud.

Build docs developers (and LLMs) love

Get started for freeTalk to us