Properties module has minimal tests: 21 files covered by a single spec

[nanaf6203-bit]

Properties module has minimal tests: 21 files covered by a single spec

Labels / Complexity: testing · Medium Complexity — Medium

Problem

src/properties/ spans 21 files (service, controller, image upload, tax submodule) yet has just 1 spec file. The listing lifecycle — create, update, search, filtering, image handling, geocoding throttle, tax — is largely unpinned. A regression in filter logic or image handling ships silently; given the module also holds the in-memory geocode throttle (#59), its behavior needs to be pinned before that migration.

Why this is architecturally hard

1. The module is a system, not a service. Listing CRUD, search filters, image upload, and tax are distinct areas; the test plan must scope each rather than one catch-all spec.
2. Prisma-heavy with submodules. Tests need the mock pattern or test database, and the tax/image submodules have their own payload shapes to cover.

Acceptance criteria

• Tests cover listing CRUD, search/filter behavior, and at least one image or tax submodule path.
• Tests run in CI via npm test.
• The PR reports the module's coverage change (npm run test:cov).

Out of scope

Changing property behavior; the geocode-throttle migration (#59).

Getting started

• src/properties/properties.service.ts — the core service
• src/properties/property-images.controller.ts and src/properties/tax/ — the submodules

Commands: npm test, npm run test:cov.

Good first files to read: src/properties/properties.service.ts, src/properties/properties.service.spec.ts.