# Gap Analysis: Tests Needed Before Refactoring

## Context

The goal of adding tests before a refactor is **regression protection** — not completeness for its own sake. Every test added should answer the question: *"If I change how this code works internally, will a test catch it if I accidentally changed the behavior?"*

---

## What's Already Well-Covered (Don't Duplicate)

- User CRUD, concurrency, referential integrity, password change, inactive user login
- Project CRUD and concurrency
- WorkOrder + nested items/parts/labor/units CRUD
- Attachments (upload/download/delete/authorization)
- Search (phrase, wildcard, tags, serial, deletion cleanup)
- Custom forms
- Pick lists
- Translations
- Event log (object log, user log, pagination)
- Tag bulk operations
- Auth rights (unauthenticated 401, unauthorized 403)
- Server health, metrics, log files

---

## Tier 1 — Critical Gaps (Block the Refactor)

These cover the most logic-dense areas where redundancies are most likely to exist. Without these, a refactor is risky.

### 1. DataList — Filtering, Sorting, Saved Filters

The single biggest gap. ~80 tests are commented out from case 4648. This is the cross-cutting query infrastructure used everywhere in the UI. A refactor of service/repository layers will almost certainly touch this.

**Add:**
- Filter by each field type: string (contains/starts-with/ends-with/equals), date range, boolean, decimal/numeric range, null/not-null
- Multi-condition AND filters
- Sort ascending/descending on multiple fields
- Pagination (limit/offset) correctness
- Saved filter CRUD: create, list, update, delete, apply
- Column view CRUD: create, update, delete, apply
- Rights enforcement: user without list rights gets 403

Maps to: `DataListController`, `DataListSavedFilterController`, `DataListColumnViewController`

### 2. Quote — Full CRUD With Nested Hierarchy

Quote is structurally parallel to WorkOrder (header → items → labor/parts/expenses/tasks/travels/units → states) but has zero test coverage. If the refactor consolidates duplicated patterns between these two, tests on both are needed.

**Add:**
- Quote header CRUD + concurrency violation
- Quote item CRUD
- At least one nested sub-type (labor or parts) CRUD
- Quote state CRUD
- Lookup by quote number (`/id-from-number/{number}`)

### 3. Customer — Core Relationships

Customer is the root of the customer hierarchy. Many other objects (WO, Quote, Contract, PM) belong to a Customer. A refactor could touch customer-related join logic.

**Add:**
- Customer CRUD + concurrency violation
- Customer alert retrieval
- Referential integrity: customer with work orders should not be deletable (or verify delete cascades correctly per business rules)

---

## Tier 2 — Important Before a Thorough Refactor

These areas have enough complexity that refactoring without coverage is risky, but slightly less immediately critical than Tier 1.

### 4. Part — Inventory and Serials

Parts have a richer data model than simple CRUD (serials, stock levels per warehouse, cost tracking). If the refactor touches inventory or cost logic:

**Add:**
- Part CRUD
- Get/update serial numbers
- Get/update stock levels
- Get/update part cost

### 5. Contract CRUD

Contracts can have complex billing rules. Even basic CRUD coverage ensures the object graph survives the refactor.

**Add:**
- Contract CRUD + concurrency violation

### 6. Preventive Maintenance (PM) CRUD

PM is structurally similar to WorkOrder (hierarchical items). If the refactor consolidates WorkOrder/PM patterns, both need coverage.

**Add:**
- PM header CRUD
- PM item CRUD
- At least one PM item sub-type CRUD

### 7. Authorization Roles

The `AuthorizationRoles` business logic file is the largest in the codebase (~64KB). A refactor here is high risk.

**Add:**
- List authorization roles
- Verify role-based rights are enforced for at least 2-3 different role types
- Verify that rights changes take effect (create a user with a role, test access, change role, re-test)

### 8. Schedule Reads

The schedule endpoint is used for the main dispatch board. Even basic read tests give a safety net.

**Add:**
- Fetch service schedule for a date range
- Fetch user schedule for a date range

---

## Tier 3 — Lower Priority (Nice to Have Before Refactor)

These are worth adding eventually but won't block a careful refactor if Tier 1 and 2 are covered.

| Area | What to Add |
|---|---|
| **Memo** | CRUD + concurrency |
| **Unit / UnitModel** | CRUD |
| **Vendor** | CRUD |
| **ServiceRate / TravelRate / TaxCode** | CRUD (simple reference data) |
| **Notification** | New count, fetch, delete one |
| **EnumList** | Get by key, list keys |
| **Name lookup** | Get name for a known object |
| **Report** | Create, list, generate data (async job pattern) |
| **GlobalBizSettings** | Fetch client settings |

---

## Cross-Cutting Concerns to Verify Everywhere

These should be confirmed on any *new* test entity, not just the ones already tested:

| Concern | Why It Matters for Refactor |
|---|---|
| **Concurrency (`ETag`/`rowVersion`)** | Optimistic locking is often in a shared base class — refactoring that class risks breaking all objects |
| **Soft delete / referential integrity** | If a shared delete handler is consolidated, it must still block deletes where referenced |
| **Custom field round-trip** | Custom fields are stored/retrieved through a shared mechanism; any refactor of that mechanism needs a test |
| **Tags round-trip** | Tags use batch operations through shared infrastructure |

---

## Recommended Order of Work

1. **DataList filtering + sorting + saved filters** — biggest risk, most logic, rebuild from scratch
2. **Quote CRUD** — parallels WorkOrder, needed to de-risk consolidation of the two
3. **Customer CRUD + referential integrity** — root of object graph
4. **Contract CRUD** — completes the main business objects
5. **Auth roles / rights behavior** — largest single business logic file
6. **Part CRUD** — inventory complexity
7. **PM CRUD** — parallels WorkOrder
8. **Schedule reads**
9. Everything in Tier 3 as capacity allows