Skip to main content

Testing Guide

How to run tests in the AI Primitives Hub extension.

For test writing patterns (style, helpers, anti-patterns, deduplication rules), see test/AGENTS.md. This file covers commands and tooling only.

Testing Architecture​

The project uses a two-tier test layout, both running under Mocha TDD style (suite / test / assert):

TierLocationRuns InPurpose
Unit / Property / E2E (mocked)test/{services,adapters,commands,ui,utils,storage,e2e}/**/*.test.tsNode.js with vscode mocked via test/mocha.setup.jsPure logic, data flow, multi-component workflows
Integration (real VS Code)test/suite/**/*.test.tsElectron via test/runExtensionTests.jsExtension activation, command registration, UI wiring

Tests compile to test-dist/ first (pnpm run compile-tests) — Mocha runs the compiled JS.

Quick Start​

# All tests (unit + integration)
LOG_LEVEL=ERROR pnpm test

# Unit / property / e2e only (no VS Code host)
LOG_LEVEL=ERROR pnpm run test:unit

# Integration tests (real VS Code)
pnpm run test:integration

# Single file (auto-compiles)
pnpm run test:one -- test/services/bundle-installer.test.ts

# Coverage
pnpm run test:coverage            # all tests
pnpm run test:coverage:unit       # unit only, c8 html report
pnpm run test:coverage:integration # integration only

Use LOG_LEVEL=ERROR to suppress debug output.

Test Directory Layout​

test/
├── adapters/           # Adapter unit tests
├── commands/           # Command handler tests
├── services/           # Service layer tests
├── storage/            # Storage tests
├── ui/                 # UI component tests
├── utils/              # Utility tests
├── e2e/                # Multi-component workflow tests (mocked VS Code)
├── suite/              # Real VS Code integration tests
├── fixtures/           # Test data and mock responses
├── helpers/            # Shared test utilities
├── mocks/              # Mock implementations
├── mocha.setup.js      # Mocks `require('vscode')` before tests load
└── vscode-mock.js      # VS Code API mock implementation

Test Types​

TypeSuffixPurpose
Unit.test.tsSingle component
Property.property.test.tsInvariant testing with fast-check
E2Etest/e2e/*.test.tsMulti-component workflows (mocked VS Code)
Integrationtest/suite/*.test.tsReal VS Code extension host

Debugging​

LOG_LEVEL=DEBUG pnpm run test:one -- test/path/to/test.ts

# Capture for analysis
LOG_LEVEL=ERROR pnpm test 2>&1 | tee test.log | tail -20

Coverage​

pnpm run test:coverage:unit    # c8 html output in coverage/

Coverage reports are written to the coverage/ directory.

Security Scanner Testing​

Scanner coverage lives in packages/core/test/domain/security/, packages/infra/test/security/, packages/app/test/security/, packages/cli/test/commands/security-scan.test.ts, and the extension's scanner tests. Run focused package tests with pnpm -C packages/<package> exec vitest run <test-path>. The isolated-engine and CLI scanner tests use the built worker. On a clean checkout, build the shared packages first:

pnpm --filter @ai-primitives-hub/core --filter @ai-primitives-hub/infra --filter @ai-primitives-hub/app --filter @ai-primitives-hub/cli build
pnpm -C packages/infra exec vitest run test/security/isolated-security-scan-engine.test.ts

Use synthetic credentials only, and cover positive cases, near misses, redaction, limits, worker isolation, cancellation, and report writes. See Security Scanner Maintenance.

What These Suites Do Not Cover​

Everything above is automated. The paths a person still has to walk by hand — installing the published extension on a clean machine, authenticating against real GitHub, confirming Copilot and Kiro actually recognize what was installed, publishing a collection through a real runner, upgrading from the previous major — are covered manually.

Start with the Golden Path Test Cases: three chained scenarios that every release must pass on both the extension and the CLI. The Full Test Plan holds all 19 plans for area-by-area coverage when a PR touches something specific.

See Also​