Proposal: Establish a Vitest-based Testing Surface

[dawgdevv]

Problem

Greplica currently relies on ad-hoc Node scripts in scripts/ for verification:

• check-transcript-bundle.js
• check-repo-context.js
• check-install-options.js
• check-graph-view.js

These scripts require a full npm run build before running, import from dist/, use raw node:assert/strict, create temporary directories manually, and provide no coverage reporting, watch mode, or CI-friendly output. As the codebase grows, this approach does not scale and makes it hard to catch regressions early.

Goal

Introduce Vitest as the primary test runner and gradually migrate existing checks into a structured test suite with:

• TypeScript-native unit tests (no build step required for development),
• isolated integration tests for CLI behavior,
• coverage reporting,
• a clear path to CI integration.

Proposed Plan

Phase 0 — Foundation

• Add vitest and @vitest/coverage-v8 as dev dependencies.
• Add vitest.config.ts configured for Node, NodeNext resolution, and .js extension imports.
• Add tests/setup.ts for shared test utilities and environment isolation.
• Add a first trivial unit test to validate the harness (e.g., isAllowedEdge).

Phase 1 — Pure Logic Unit Tests

Add co-located .test.ts files for modules with no I/O:

• libs/knowledge-graph/edge.test.ts
• libs/knowledge-graph/proposal.test.ts
• libs/knowledge-graph/validate-proposal.test.ts
• libs/config/greplica-config.test.ts
• libs/session-transcript/markdown.test.ts
• libs/install/paths.test.ts

Phase 2 — Service & Repository Tests

Add isolated tests using temporary SQLite databases:

• libs/storage/sqlite/repository.test.ts
• libs/knowledge-graph/service.test.ts
• Mock embedder to avoid slow model downloads in unit tests.

Phase 3 — CLI Integration Tests

Replace the scripts/check-*.js files with integration tests under tests/integration/:

• transcript-bundle.test.ts
• repo-context.test.ts
• install-options.test.ts
• graph-view.test.ts

Run these against the built CLI (dist/apps/cli/main.js) in isolated GREPLICA_HOME / temp repo environments.

Phase 4 — Optional Smoke Tests

• Migrate scripts/smoke-*.mjs to optional @smoke tagged tests.

Phase 5 — CI & Coverage

• Add a GitHub Actions workflow running typecheck, test, and test:coverage.
• Set an initial low coverage threshold and raise it incrementally.

Open Questions / Tradeoffs

1. Test file location: co-located .test.ts files vs. a mirrored tests/ directory?
   Proposal: co-located for unit tests, tests/integration/ for CLI tests.

2. Source vs. dist for unit tests: Vitest can test libs/**/*.ts directly. CLI integration still needs dist/.
   Proposal: unit tests against source; integration tests against built CLI.

3. Fate of old scripts: delete scripts/check-*.js once Vitest equivalents are in place and CI-green?
   Proposal: remove them to avoid duplication.

4. Default test command scope: should npm test include CLI integration tests? They spawn subprocesses and are slower.
   Proposal: npm test runs fast unit + service tests; npm run test:integration runs CLI checks.

5. External dependencies: local embeddings download a model; OpenAI needs an API key.
   Proposal: mock embedder in unit tests; skip OpenAI tests silently when the key is missing.

Acceptance Criteria

• npm test runs Vitest and passes.
• Existing behavior verified by scripts/check-*.js is covered by equivalent Vitest tests.
• npm run test:coverage produces a coverage report.
• CI runs the test suite on PRs.
• Old ad-hoc check scripts are removed.

Labels

enhancement, testing, good first issue (for individual phases)

[dawgdevv]

Hey @kushalpatil07

I opened a proposal for adding Vitest to Greplica

Right now our only "tests" are four manual Node scripts that require a full build and have no coverage or CI. That makes regressions easy to miss, slows down development, and blocks reliable automation.

The goal is to introduce Vitest and migrate those scripts into proper unit + integration tests.

If you are convinced by this proposal assign this to me i would like to work on this or we can discuss it further

[kushalpatil07]

Yes this is making sense. But lets not go fully deep here.
If you can move the few adhoc scripts that we have to the vite runner. That will be good.
Then later we can add a lot more tests in other issues/PRs