Add request specs for properties CRUD and resolve endpoint

ldraney commented

2026-05-29 23:35:50 +00:00

Owner

Type

Feature

Lineage

Standalone — identified in testing strategy audit (docs/testing-strategy.md).

Repo

ldraney/landscaping-assistant

User Story

As a developer,
I want request specs covering every properties endpoint and the resolve flow,
So that CI catches regressions in the core CRUD and address resolution before they reach production.

Context

A testing strategy audit revealed that the properties controller has significant gaps in request spec coverage. The resolve endpoint — the core address resolution flow — has zero test coverage. show, edit, update, and create are also untested. The work queue, weekly view, uploads, and health endpoints all have solid request specs, but properties CRUD (the most-touched controller) does not.

Geocoding is client-side only (Stimulus controllers calling Nominatim directly). There is no server-side NominatimService to test. This ticket covers server-side request specs only.

File Targets

Files the agent should create:

spec/requests/properties_spec.rb — extend existing file with specs for show, edit, update, create, resolve

Files the agent should read for context:

app/controllers/properties_controller.rb — all actions
app/models/property.rb — validations, associations
config/routes.rb — route definitions
docs/testing-strategy.md — gap analysis
spec/requests/work_queue_items_spec.rb — reference for test style/patterns
spec/requests/uploads_spec.rb — reference for test style/patterns

Files the agent should NOT touch:

Gemfile — no new gems needed
.woodpecker.yaml — no CI changes
Any app/ code — this is test-only work

Acceptance Criteria

GET /properties/:id returns 200 with property content
GET /properties/:id/edit returns 200 with form
POST /properties creates a property and redirects
POST /properties with invalid params returns unprocessable_entity
PATCH /properties/:id updates and redirects
PATCH /properties/:id with invalid params re-renders edit
POST /properties/resolve with street + number finds or creates property, returns JSON
POST /properties/resolve with existing address returns the existing property
POST /properties/resolve without street creates property with client_name only
POST /properties/resolve with service_ids assigns services
All existing specs in properties_spec.rb continue to pass
bundle exec rspec passes with zero failures

Test Expectations

All tests are request specs (type: :request)
Tests follow the existing pattern in spec/requests/ (let! for setup, describe blocks per action)
No mocks or stubs needed — all server-side with real Postgres
Run command: bundle exec rspec spec/requests/properties_spec.rb

Constraints

Follow existing test patterns in spec/requests/work_queue_items_spec.rb and uploads_spec.rb
Use Property.create! for setup (matching existing convention, not factories)
All POST/PATCH redirects use status: :see_other (303) per Turbo Drive convention documented in docs/hotwire.md
Do not introduce FactoryBot or other new test dependencies

Checklist

PR opened
Tests pass
No unrelated changes

landscaping-assistant — project board

### Type Feature ### Lineage Standalone — identified in testing strategy audit (docs/testing-strategy.md). ### Repo `ldraney/landscaping-assistant` ### User Story As a developer, I want request specs covering every properties endpoint and the resolve flow, So that CI catches regressions in the core CRUD and address resolution before they reach production. ### Context A testing strategy audit revealed that the properties controller has significant gaps in request spec coverage. The `resolve` endpoint — the core address resolution flow — has zero test coverage. `show`, `edit`, `update`, and `create` are also untested. The work queue, weekly view, uploads, and health endpoints all have solid request specs, but properties CRUD (the most-touched controller) does not. Geocoding is client-side only (Stimulus controllers calling Nominatim directly). There is no server-side NominatimService to test. This ticket covers server-side request specs only. ### File Targets Files the agent should create: - `spec/requests/properties_spec.rb` — extend existing file with specs for show, edit, update, create, resolve Files the agent should read for context: - `app/controllers/properties_controller.rb` — all actions - `app/models/property.rb` — validations, associations - `config/routes.rb` — route definitions - `docs/testing-strategy.md` — gap analysis - `spec/requests/work_queue_items_spec.rb` — reference for test style/patterns - `spec/requests/uploads_spec.rb` — reference for test style/patterns Files the agent should NOT touch: - `Gemfile` — no new gems needed - `.woodpecker.yaml` — no CI changes - Any app/ code — this is test-only work ### Acceptance Criteria - [ ] `GET /properties/:id` returns 200 with property content - [ ] `GET /properties/:id/edit` returns 200 with form - [ ] `POST /properties` creates a property and redirects - [ ] `POST /properties` with invalid params returns unprocessable_entity - [ ] `PATCH /properties/:id` updates and redirects - [ ] `PATCH /properties/:id` with invalid params re-renders edit - [ ] `POST /properties/resolve` with street + number finds or creates property, returns JSON - [ ] `POST /properties/resolve` with existing address returns the existing property - [ ] `POST /properties/resolve` without street creates property with client_name only - [ ] `POST /properties/resolve` with service_ids assigns services - [ ] All existing specs in properties_spec.rb continue to pass - [ ] `bundle exec rspec` passes with zero failures ### Test Expectations - [ ] All tests are request specs (type: :request) - [ ] Tests follow the existing pattern in spec/requests/ (let! for setup, describe blocks per action) - [ ] No mocks or stubs needed — all server-side with real Postgres - Run command: `bundle exec rspec spec/requests/properties_spec.rb` ### Constraints - Follow existing test patterns in spec/requests/work_queue_items_spec.rb and uploads_spec.rb - Use Property.create! for setup (matching existing convention, not factories) - All POST/PATCH redirects use status: :see_other (303) per Turbo Drive convention documented in docs/hotwire.md - Do not introduce FactoryBot or other new test dependencies ### Checklist - [ ] PR opened - [ ] Tests pass - [ ] No unrelated changes ### Related - `landscaping-assistant` — project board