Testing Strategy & Fixtures

Relevant source files

The following files were used as context for generating this wiki page:

• CLAUDE.md
• src/redact.rs
• src/gates.rs
• src/consumer/manifest.rs
• src/curate.rs
• src/backup.rs
• src/capture.rs
• src/replay.rs
• src/isolation.rs
• src/search.rs

Testing in the oboete project ensures the integrity of lightweight coding agent memory. The strategy combines standard Rust unit testing with specialized performance measurement tools and historical event fixtures. The system validates security redaction, claim gating logic, and database recovery mechanisms under high-load and failure scenarios.

The project relies on cargo test for continuous integration and the oboete replay command for performance benchmarking against real-world datasets.

Sources: CLAUDE.md:12-14, src/replay.rs:1-5

Performance Benchmarking & Replay

The project uses a replay system to measure hook latency and resource consumption. The oboete replay command processes JSONL fixtures, simulating agent interactions to prove stability and speed.

Replay Execution Flow

The replay system simulates the hook path to measure pure store costs and real process spawn times.

The diagram shows how oboete replay iterates through a fixture to generate a performance report.
Sources: src/replay.rs:18-40

Replay Metrics

Metric	Purpose	derivation
hook_in_process_us	Measures pure database overhead	p50, p95, and max microseconds
hook_spawn_ms	Measures total agent wait time	Startup + Redaction + Insert latency
backup_export	Validates D11 segment sealing	Duration and segment size (KB)
vmhwm_kb	Monitors peak resident memory	Read from /proc/self/status

The "fixture of record" for these measurements is ../free-mem/test/fixtures/events-1000.jsonl.
Sources: CLAUDE.md:27, src/replay.rs:80-100

Security Redaction Testing

The redaction system uses gitleaks rules to mask secrets. Tests verify that the system correctly identifies known secret shapes while preserving normal prose.

Masking Validation Logic

Tests ensure that every byte is scanned and that the redaction ledger never contains the actual secret values.

The flowchart describes the verification process for masking known secret shapes.
Sources: src/redact.rs:444-460, src/redact.rs:500-515

Critical Redaction Test Cases

• Secret Straddling: Ensures tokens split across head/tail cuts in oversized fields remain masked.
• Context Preservation: Verifies that rules needing far-off context (e.g., curl -u) still function after text cuts.
• Multibyte Safety: Confirms that character boundaries in Japanese text are respected during redaction.

Sources: src/redact.rs:518-535, src/redact.rs:570-580

Claim Gating & Curation Logic

Testing for src/gates.rs and src/curate.rs focuses on the "none tier" of claim processing, which functions without model calls. It uses mock session windows to verify if drafts should be kept, lowered, or dropped.

Gating Logic Verification

The check function is tested against various user inputs to ensure decisions meet "MUST-M" requirements.

The sequence diagram illustrates how the gating logic is exercised during unit tests.
Sources: src/gates.rs:114-140, src/gates.rs:555-575

Automated Threshold Tuning

Oboete uses the "dev split" of its data to tune various constants used in gating:

• PASTE_CHARS: Minimum length of text shared with a tool output to be considered a "paste".
• BARE_CHARS: Maximum length of an acceptance turn that contains no original user words.
• TAU: Trigram similarity threshold for paraphrased content.

Sources: src/gates.rs:90-100, src/gates.rs:440-450

Database Integrity & Recovery Testing

The project implements a robust recovery strategy for raw.db. Tests in src/backup.rs simulate corruption to verify the restoration process.

Restoration Sequence

When corruption is detected, the worker quarantines the file and rebuilds it from sealed zstd segments.

The sequence diagram shows the automated recovery of a damaged raw database.
Sources: src/backup.rs:277-310, src/backup.rs:430-450

Recovery Scenarios

• Damaged Segments: Verifies that mismatching checksums cause segments to be skipped and set aside.
• Lost Commits: Tests that if raw.db loses its latest commits, backups past raw's current end are quarantined to avoid reuse conflicts.
• Sidecar Cleanup: Ensures that -wal and -shm files are moved along with the main database during quarantine.

Sources: src/backup.rs:160-175, src/backup.rs:215-225

Isolation Testing

The isolation gate (src/isolation.rs) ensures that curator CLIs (like Claude or Codex) run only when they cannot perform unauthorized actions.

Capability Probing

Instead of testing model obedience, the gate probes the CLI's capability:

1. Version Check: Confirm the CLI responds to --version.
2. Sandbox Validation: Probes the codex sandbox profile.
3. Action Refusal: Attempts cat, touch, and curl through the agent's tools to ensure they are refused by the sandbox.

Sources: src/isolation.rs:1-15, src/isolation.rs:125-150

Summary

oboete's testing strategy prioritizes data safety and performance. Security masking is verified via exhaustive scanning tests. Curation logic uses heuristic thresholds tuned against real development data. Database reliability is guaranteed through automated corruption detection and a checksummed segment-based restoration system. Benchmark fixtures allow developers to verify that changes do not introduce latency regressions for agent interactions.

Sources: CLAUDE.md:27, src/backup.rs:430-440, src/replay.rs:70-80