Testing Strategy
Relevant source files
The following files were used as context for generating this wiki page:
The Augenblick project employs a multi-layered testing strategy designed to ensure the reliability of its note-taking functionality, data persistence, and UI behavior. The strategy primarily utilizes Vitest as the test runner and focus on unit and integration testing of React components, Zustand stores, and the Tauri-specific logic via shims and mocks.
The testing architecture ensures that core features like auto-expiry, note persistence (Draft vs. Saved), and the Markdown editor maintain parity with the intended design. It also includes specific regression testing protocols where bugs are addressed by adding corresponding tests.
Sources: package.json:11, AGENTS.md:28, plans/migration.md:195-201
Test Infrastructure and Environment
The project uses a modern JavaScript testing stack centered around Vitest and React Testing Library. Configuration is managed to handle both the React frontend and the Tauri-integrated backend logic.
Frameworks and Utilities
| Tool | Purpose |
|---|---|
| Vitest | Main test runner for unit and integration tests. |
| React Testing Library | Used for rendering and asserting on React components. |
| JSDOM | Provides the browser environment for DOM testing. |
| Tauri Shim | A custom web-based implementation of Tauri IPC to test logic without a native backend. |
Sources: package.json:54-62, src/test/lib/tauriShim.test.ts:3-10
The following diagram illustrates the flow of a test execution within the Augenblick environment, showing how UI components and stores interact with mocks and shims.
The testing environment leverages vi.mock extensively to isolate components from native Tauri plugins like updater, process, and dialogs.
Sources: src/test/App.test.tsx:8-23, src/test/stores/notes.test.ts:4-22
Component and Feature Testing
Testing at the component level focuses on the interaction between the UI and the underlying state. This includes the Markdown editor, the application shell, and user actions.
Editor Testing
The Tiptap-based editor is tested to ensure that content updates trigger appropriate store changes and that the editor respects operational constraints like readOnly mode.
- Content Synchronization: Verifies that external value changes sync into the editor and that internal edits trigger
onChangecallbacks. - Event Handling: Tests custom window events like
augenblick:focus-editor. - Security & Interaction: Ensures links only open on modifier clicks (Meta/Ctrl) and that paste events correctly parse Markdown.
Sources: src/test/features/Editor.test.tsx:75-103, src/test/features/Editor.test.tsx:157-183
App Lifecycle and Updater
Tests for the main App component focus on native integration points, specifically the update cycle.
Sources: src/test/App.test.tsx:110-153
State Management and Data Logic
The project's logic is heavily concentrated in Zustand stores. Testing ensures that the complex state transitions—such as note creation, draft auto-saving, and expiry—are handled correctly.
Notes Store Strategy
The notesStore tests simulate the full lifecycle of a note, including its transition from a draft to a saved file.
- Persistence Logic: Validates that drafts are written to disk using a debounced timer (500ms) while saved notes require explicit save actions.
- Reordering: Tests the undo/redo stack for note reordering, supporting a depth of up to 20 actions.
- Cleanups: Verifies that local state (content cache and dirty flags) is purged when notes are expired or deleted.
Sources: src/test/stores/notes.test.ts:168-185, src/test/stores/notes.test.ts:333-350, plans/migration.inventory.md:120-125
Expiry and Utility Logic
A dedicated test suite handles the mathematical logic for the "expiry ring" and auto-deletion.
- expiryProgress: Computes the percentage of time remaining for a note based on
lastInteraction. - expiryStatus: Maps progress percentages to visual states:
fresh(≥50%),aging(≥25%),warning(≥10%), anddanger(<10%).
Sources: src/test/lib/expiry.test.ts:4-15, src/test/lib/expiry.test.ts:18-28
Tauri Integration and IPC Testing
Because the backend is written in Rust, the frontend tests use two primary methods to verify IPC:
- API Mocks: Directly mocking the
invokecalls to verify that the frontend sends the correct commands and arguments to the Rust core. - Tauri Web Shim: A comprehensive mock that implements a subset of the Rust logic in JavaScript, using
localStorageto simulate the SQLite database. This allows for integration testing of the "Draft vs Saved" logic without compiling the Rust backend.
IPC Command Verification
| Command | Verified Inputs | Source |
|---|---|---|
note_create | None | src/test/lib/api.test.ts:20 |
note_write_draft | id, content | src/test/lib/api.test.ts:24 |
note_save_as | id, path, content | src/test/lib/api.test.ts:26 |
note_pin | id, pinned (bool) | src/test/lib/api.test.ts:31 |
settings_set | key, value | src/test/lib/api.test.ts:34 |
Shim Logic Coverage
The web shim (tested in tauriShim.test.ts) provides a high-fidelity environment for testing:
- Title Derivation: Verifies that titles are correctly extracted from Markdown content (e.g., stripping
#and handling empty content). - Pin Limits: Enforces the 5-note pin limit.
- Error States: Simulates "Note not found" errors and unsupported commands.
Sources: src/test/lib/tauriShim.test.ts:26-38, src/test/lib/tauriShim.test.ts:123-140
Conclusion
The testing strategy for Augenblick is focused on protecting the core value proposition: the automated lifecycle of notes. By combining store unit tests, component interaction tests, and a high-fidelity Tauri shim, the project ensures that note data is never lost unexpectedly while maintaining the "disappearing" behavior. Final verification is governed by a manual QA checklist to catch edge cases in native window behavior that automated tests cannot reach.
Sources: plans/migration.qa.md