Source: codebase audit, 2026-06-11 (audit finding F9, Tier 3)
Severity: Low
Category: Test coverage
Problem
`statusTone()` is exported and used by ≥3 views (`EtlView`, `PiiReviewView`, `SurveyEditorView`) to map a status string to a Badge tone. The colocated Badge.test.tsx only tests the component, not the tone-mapping logic.
If a new status value is added (e.g. `'paused'`, `'queued'`) the fallback tone would silently apply with no test catching it.
Suggested approach
Add a unit test in `Badge.test.tsx`:
```ts
describe('statusTone', () => {
it('maps known statuses to expected tones', () => {
expect(statusTone('success')).toBe(...);
expect(statusTone('failed')).toBe(...);
expect(statusTone('running')).toBe(...);
// etc — enumerate every status used by the views
});
it('falls back to a default for unknown statuses', () => { ... });
});
```
Priority
Nit. Add it opportunistically next time `Badge.tsx` is touched.
Source: codebase audit, 2026-06-11 (audit finding F9, Tier 3)
Severity: Low
Category: Test coverage
Problem
`statusTone()` is exported and used by ≥3 views (`EtlView`, `PiiReviewView`, `SurveyEditorView`) to map a status string to a Badge tone. The colocated Badge.test.tsx only tests the component, not the tone-mapping logic.
If a new status value is added (e.g. `'paused'`, `'queued'`) the fallback tone would silently apply with no test catching it.
Suggested approach
Add a unit test in `Badge.test.tsx`:
```ts
describe('statusTone', () => {
it('maps known statuses to expected tones', () => {
expect(statusTone('success')).toBe(...);
expect(statusTone('failed')).toBe(...);
expect(statusTone('running')).toBe(...);
// etc — enumerate every status used by the views
});
it('falls back to a default for unknown statuses', () => { ... });
});
```
Priority
Nit. Add it opportunistically next time `Badge.tsx` is touched.