Add importer and redaction test coverage#5
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Greptile SummaryThis PR adds unit test coverage for the redaction and importer modules that were already implemented, and wires
Confidence Score: 4/5Safe to merge; the only findings are test-file hygiene issues that do not affect runtime behavior. All four changed files are tests and CI configuration with no changes to production code. The test assertions are correctly aligned with the implementations they cover. Two minor concerns: synthetic credential strings in the redact tests closely match real secret formats and may trigger push-protection scanners on future branches, and the double-counting of a single env-assignment secret across the api-key and env-secret categories is not asserted, leaving that behavior untested. src/lib/redaction/redact.test.ts — synthetic credential patterns and uncovered double-count behavior. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[CI: vp test] --> B{Tests pass?}
B -- No --> FAIL[Workflow fails]
B -- Yes --> C[vp check]
C --> D[vp run build]
subgraph redact.test.ts
R1[redacts API keys / tokens / emails / paths / URL secrets]
R2[redacts private key blocks]
end
subgraph parse.test.ts
P1[generic transcript parsing]
P2[generic JSON / JSONL parsing]
P3[normalizeCandidate stats + data-completeness]
P4[Claude Code JSONL native parser]
P5[Cursor markdown + fallback parser]
P6[Codex rollout JSONL parser]
P7[Pi session JSONL parser]
end
A -.runs.-> redact.test.ts
A -.runs.-> parse.test.ts
Reviews (1): Last reviewed commit: "add gh actions for tests" | Re-trigger Greptile |
| const input = [ | ||
| "OPENAI_API_KEY=sk-proj_abcdefghijklmnopqrstuvwxyz123456", | ||
| "Authorization: Bearer abcdefghijklmnopqrstuvwxyz1234567890", | ||
| "GitHub token ghp_abcdefghijklmnopqrstuvwxyz123456", | ||
| "Email daniel@example.com", | ||
| "Path /Users/daniel/Code/private/.env", | ||
| "URL https://example.com/callback?token=super-secret-value&next=/app", | ||
| ].join("\n"); |
There was a problem hiding this comment.
Synthetic credentials match real token formats
The strings sk-proj_abcdefghijklmnopqrstuvwxyz123456, ghp_abcdefghijklmnopqrstuvwxyz123456, and the Bearer token value all satisfy the exact length and prefix constraints that GitHub secret scanning and similar tools use to detect live credentials. GitHub's push-protection scanner checks for the ghp_ pattern specifically; future pushes or forks may be blocked or flagged even though the values are clearly synthetic. Consider using obviously-invalid prefixes such as sk-test- or ghp-FAKE- that token scanners are trained to ignore.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
| expect(countFor(result, "env-secret")).toBe(1); | ||
| expect(countFor(result, "token")).toBeGreaterThanOrEqual(2); | ||
| expect(countFor(result, "email")).toBe(1); | ||
| expect(countFor(result, "absolute-path")).toBe(1); | ||
| expect(countFor(result, "url-secret")).toBe(1); | ||
| }); |
There was a problem hiding this comment.
Double-counting behavior between
api-key and env-secret rules is untested
Because the redaction rules run sequentially, OPENAI_API_KEY=sk-proj_… first triggers the api-key rule (replacing the value with [REDACTED:API_KEY], count api-key=1), then the env-secret rule fires again on the already-redacted line (count env-secret=1). The final text is correct ([REDACTED:ENV_SECRET]), but categories will contain both { category: "api-key", count: 1 } and { category: "env-secret", count: 1 } for what was a single secret, potentially inflating the reported redaction count shown to users. No assertion covers countFor(result, "api-key"), so a future fix that eliminates the double-count would not be caught by this test.
Stack Context
This PR adds automated test coverage for the Peek MVP features that are already implemented from
plans/product-plan.md.What?
Why?
The product plan calls for unit tests around redaction, import parsing, normalization, and data-completeness behavior. These tests lock in the currently implemented client-side logic before adding more import/storage/analysis features.
Validation
vp testpasses: 9 testsvp checkpasses with 0 errors and 1 existing warning insrc/lib/components/ui/liquid-metal-button/liquid-metal-button.svelte