What problem does it solve? Writing and maintaining Vitest tests in a large monorepo is error-prone: developers run the full 3000+ test suite unnecessarily, mock the wrong layers, and waste time fixing over-specified tests that break on every refactor. This Skill provides the project's testing conventions, commands, and decision frameworks. ## Core Features & Use Cases - Targeted test execution: Run single test files with bunx vitest run for webapp, packages, database (client-db/server-db), and desktop targets instead of the full suite. - Mocking and coverage conventions: Prefer vi.spyOn over vi.mock, render real @lobehub/ui/base-ui components, and use real database integration via getTestDB() with user-isolation tests. - Failing-test triage: A decision checklist for whether to fix behavior tests or delete over-specified param-forwarding tests after refactors. - Use Case: When adding a new database model under packages/database/src/models/, follow the sibling __tests__ convention, guard BM25 blocks with describe.skipIf(!isServerDB), and verify ownership scoping. ## Quick Start Ask the assistant to write or fix a Vitest test for a specific file, such as a database model or Zustand store action, following the project testing guide.