-
Notifications
You must be signed in to change notification settings - Fork 0
Testing Strategy
Relevant source files
- package-lock.json
- package.json
- src/lib/fit.test.ts
- src/lib/fit.ts
- src/lib/highlight.test.ts
- src/lib/highlight.ts
- src/lib/jobDetail.test.ts
- src/lib/jobDetail.ts
- src/lib/jobStatus.test.ts
- src/lib/jobStatus.ts
- src/lib/markdown.test.ts
- src/lib/markdown.ts
- src/lib/pipeline.test.ts
- src/lib/rolesView.test.ts
- src/lib/rolesView.ts
- vitest.config.ts
Lodestar employs a dual-language testing strategy to ensure the integrity of its Rust-based backend (data modeling, pipeline logic, scoring) and its TypeScript-based frontend (state management, UI formatting, security).
Rust tests are primarily implemented as inline modules within the source files they test, utilizing #[cfg(test)]. This allows for testing private functions and keeping tests close to the implementation.
To test the job-fetch pipeline and external integrations without incurring API costs or requiring network access, the codebase uses several "Fake" implementations of core traits:
-
FakeScraper: Implements theScrapertrait. It returns pre-defined HTML strings based on the input URL, allowing the pipeline to be tested against specific DOM structures. -
FakeLlm: Implements theLlmtrait. It returns static or scripted JSON responses to simulate LLM-based structuring and research. - Mock Keychain: Used in
src-tauri/src/secrets.rsto simulate the OS keychain for CI environments or local testing, ensuring that secret-dependent logic (like API key retrieval) functions without real hardware backing.
- Note Primitives: Tests for frontmatter splitting, YAML scalar encoding, and slug generation.
- Fit Scoring Engine: Unit tests in
src-tauri/src/fit.rsverify the two-layer rubric, ensuring that dealbreakers correctly collapse scores to zero and that seniority track logic (IC vs. Management) branches correctly. - Task Queue: Tests for
SqliteQueueensure atomicity ofclaim_nextand correct behavior of exponential backoff.
The frontend uses Vitest for unit testing Svelte-adjacent logic and utility functions. The configuration is defined in vitest.config.ts and includes a jsdom environment for tests requiring DOM access package.json#34-39
A significant portion of the frontend tests focus on ensuring that the UI correctly interprets data provided by the Rust backend.
| Test File | Focus Area | Key Functions Tested |
|---|---|---|
jobStatus.test.ts |
State machine transitions |
nextHumanStatuses, classifyStatus
|
fit.test.ts |
Score categorization | fitBand |
rolesView.test.ts |
Sorting and mapping |
sortRoles, outcomeBySlug
|
jobDetail.test.ts |
Markdown sectioning |
extractSection, jobSections, hasDealbreaker
|
The frontend mirrors the backend's status transition rules exactly. Tests in src/lib/jobStatus.test.ts verify that human-settable transitions (e.g., new → skipped) are correctly identified, while terminal states like applied return no further transitions src/lib/jobStatus.test.ts#93-125
Because Lodestar renders LLM-generated content, security is a primary concern. src/lib/markdown.test.ts ensures that DOMPurify correctly strips unsafe elements:
- Script Injection: Verifies
<script>tags are removed src/lib/markdown.test.ts#12-16 - Event Handlers: Verifies
onerrorand other inline handlers are stripped src/lib/markdown.test.ts#18-21 - Unsafe Schemes: Verifies
javascript:URLs are neutralized while preserving the anchor text src/lib/markdown.test.ts#23-29
The following diagram maps how natural language concepts used in the UI (like "Strong Fit" or "Applied") map to specific code entities and their corresponding tests.
UI Mapping: Concepts to Entities
flowchart LR
subgraph subGraph2 ["Test Entity Space"]
FT["fit.test.ts"]
JT["jobStatus.test.ts"]
PT["pipeline.test.ts"]
end
subgraph subGraph1 ["Code Entity Space (src/lib/)"]
FB["fitBand() in fit.ts"]
JS["JOB_STATUSES in job.ts"]
PL["phaseLabel() in pipeline.ts"]
end
subgraph subGraph0 ["Natural Language (UI)"]
NB["'Strong Fit'"]
ST["'Applied'"]
MS["'Retrying via stealth proxy...'"]
end
NB --> FB
ST --> JS
MS --> PL
FB --> FT
JS --> JT
PL --> PT
Sources: src/lib/fit.ts#7-14src/lib/fit.test.ts#1-70src/lib/jobStatus.ts#59-75src/lib/jobStatus.test.ts#93-125src/lib/pipeline.test.ts#22-27
Testing the pipeline requires verifying the transition between stages. The TypeScript phaseLabel function is used to provide telemetry to the user, and its accuracy is critical for debugging long-running scrapes.
Pipeline Telemetry Flow
flowchart LR
subgraph Verification
T["pipeline.test.ts"]
end
subgraph subGraph1 ["Frontend Telemetry (TypeScript)"]
PL["phaseLabel()"]
VS["Step Strip UI"]
end
subgraph subGraph0 ["Pipeline Execution (Rust)"]
RS["runner.rs"]
ST["steps.rs"]
end
RS --> ST
ST --> PL
PL --> VS
PL --> T
Sources: src/lib/pipeline.test.ts#4-56src/lib/jobStatus.ts#1-11
The jobDetail.ts utility is responsible for parsing the specific Markdown structure written by the Rust pipeline. It uses extractSection to isolate LLM-generated analysis from the rest of the note.
- Heading Match: Matches a line where
.trim()equals the target heading src/lib/jobDetail.ts#15-25 - Stop Condition: Collection stops at the next
##heading but ignores###subheadings, mirroring the Rustextract_sectionlogic src/lib/jobDetail.ts#32-37 - Section Mapping: Maps specific headers like
## JD — structured(using the U+2014 em-dash) to thejdStructuredproperty src/lib/jobDetail.ts#48-60
Sources: src/lib/jobDetail.ts#1-60src/lib/jobDetail.test.ts#9-72