Skip to content

Testing Strategy

Chazona Baum edited this page Jun 24, 2026 · 1 revision

Relevant source files

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).

Backend: Rust Unit Testing

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.

Mocking Infrastructure

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 the Scraper trait. It returns pre-defined HTML strings based on the input URL, allowing the pipeline to be tested against specific DOM structures.
  • FakeLlm: Implements the Llm trait. It returns static or scripted JSON responses to simulate LLM-based structuring and research.
  • Mock Keychain: Used in src-tauri/src/secrets.rs to simulate the OS keychain for CI environments or local testing, ensuring that secret-dependent logic (like API key retrieval) functions without real hardware backing.

Core Rust Test Areas

  1. Note Primitives: Tests for frontmatter splitting, YAML scalar encoding, and slug generation.
  2. Fit Scoring Engine: Unit tests in src-tauri/src/fit.rs verify the two-layer rubric, ensuring that dealbreakers correctly collapse scores to zero and that seniority track logic (IC vs. Management) branches correctly.
  3. Task Queue: Tests for SqliteQueue ensure atomicity of claim_next and correct behavior of exponential backoff.

Frontend: Vitest-based TypeScript Testing

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

UI Logic & State Transformation

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

Job Status State Machine

The frontend mirrors the backend's status transition rules exactly. Tests in src/lib/jobStatus.test.ts verify that human-settable transitions (e.g., newskipped) are correctly identified, while terminal states like applied return no further transitions src/lib/jobStatus.test.ts#93-125

Markdown & Security

Because Lodestar renders LLM-generated content, security is a primary concern. src/lib/markdown.test.ts ensures that DOMPurify correctly strips unsafe elements:

Natural Language to Code Entity Space: UI Logic

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
Loading

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

Data Flow in Pipeline Testing

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
Loading

Sources: src/lib/pipeline.test.ts#4-56src/lib/jobStatus.ts#1-11

Implementation Details: Markdown Extraction

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 Rust extract_section logic src/lib/jobDetail.ts#32-37
  • Section Mapping: Maps specific headers like ## JD — structured (using the U+2014 em-dash) to the jdStructured property src/lib/jobDetail.ts#48-60

Sources: src/lib/jobDetail.ts#1-60src/lib/jobDetail.test.ts#9-72

Clone this wiki locally