CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/js-unit-tests

JavaScript/TypeScript unit testing with Jest and Vitest as co-primary frameworks - install, config (`jest.config.js` / `vite.config.ts` test block), mocking (`jest.fn`/`jest.mock`/`jest.spyOn`, `vi.fn`/`vi.mock`/`vi.spyOn`, `__mocks__/`, fake timers), coverage (Istanbul/babel vs v8 providers, `coverageThreshold` gating), watch mode, and CI (`jest --ci`, `vitest run`, JUnit XML). Includes framework choice (Vite project → Vitest, otherwise Jest; always match an existing convention), test-authoring conventions (framework detection from package.json + config files, ESM vs CJS, no fabricated exports), and references for Mocha maintenance, Jasmine/Karma-to-Jest migration via jest-codemods, and deep Jest/Vitest coverage analysis. Use for any JS/TS unit-test task: setting up a framework, writing or mocking tests, gating coverage, or wiring CI.

93

Quality

93%

Does it follow best practices?

Impact

Average score across 10 eval scenarios

SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

Quality

Content

86%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured, highly actionable lifecycle guide with executable code at every step and clean progressive disclosure to three real reference files. It loses a little on conciseness (light framing prose) and workflow clarity (the coverage-gate validation loop is referenced out rather than inline).

Suggestions

Tighten the Overview: drop the quoted Vitest docs line and reduce the two framework bullets to one-line role tags, since the Choosing-a-framework section already carries the decision logic.

Pull the coverage-gate verification loop ('run with a critical-path file below threshold, confirm non-zero exit') inline into Step 5 so the validate→fix→retry checkpoint isn't only in references/jest-coverage.md.

Trim gotcha prose where the code already self-documents (e.g. the `testEnvironment` default-change note can be a one-line comment in the config block).

DimensionReasoningScore

Conciseness

Dense and assumes Claude's competence — no 'what is a unit test' padding, and gotchas are non-obvious (testEnvironment default change across Jest versions, vi.mock hoisting leak) — but the Overview's framing bullets and the quoted Vitest docs line are slightly beyond the minimum needed, keeping it just under lean-perfect.

4 / 5

Actionability

Copy-paste-ready throughout: install commands, complete `jest.config.js`/`vite.config.ts` blocks, runnable test files, mock/snippet code, and CI YAML with pinned flags (`--maxWorkers=2`, `vitest run --typecheck`) covering the common cases.

5 / 5

Workflow Clarity

A clear Step 1–6 sequence (Install→First test→Config→Mocking→Coverage→Watch/CI) with concrete commands and a 'stop and ask' checkpoint in Authoring conventions, but the explicit validate→fix→retry feedback loop for the coverage gate lives in the reference rather than inline, leaving a minor validation gap.

4 / 5

Progressive Disclosure

Clear overview with well-signaled one-level-deep references — `references/mocha.md`, `references/legacy-migration.md`, and `references/jest-coverage.md` (all verified present) — keeping deep dives (Mocha maintenance, legacy migration, coverage internals) out of the main body while the core lifecycle stays inline.

5 / 5

Total

18

/

20

Passed

Description

96%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

An exceptionally specific, trigger-rich description that names concrete APIs, file extensions, and an explicit 'Use for...' clause covering both what and when. The only soft spot is implicit boundary-setting against the surrounding qa-test-* family.

DimensionReasoningScore

Specificity

Lists multiple concrete actions with specific APIs — install, config (`jest.config.js`/`vite.config.ts`), mocking (`jest.fn`/`jest.mock`/`jest.spyOn`, `vi.*`, `__mocks__/`, fake timers), coverage (Istanbul/babel vs v8, `coverageThreshold`), watch, and CI (`jest --ci`, `vitest run`, JUnit XML) — comprehensive coverage of the framework lifecycle.

5 / 5

Completeness

Clearly answers 'what' (the full per-framework lifecycle) and 'when' with an explicit trigger clause: 'Use for any JS/TS unit-test task: setting up a framework, writing or mocking tests, gating coverage, or wiring CI.'

5 / 5

Trigger Term Quality

Natural terms users say — 'unit testing', 'Jest', 'Vitest', 'mocking', 'coverage', 'CI', 'unit tests' — plus synonyms (Jest/Vitest) and file extensions (`jest.config.js`, `vite.config.ts`, `__mocks__/`); the jargon (Istanbul/v8) is additive specificity rather than a replacement for natural language.

5 / 5

Distinctiveness Conflict Risk

Clear niche (Jest/Vitest unit-test framework lifecycle) with distinct triggers, but it lives in a dense testing-skill ecosystem (qa-test-review, qa-test-data, qa-time, qa-test-reporting) where 'mocking'/'coverage' phrasing has minor overlap risk; the body carves those boundaries but the description alone leaves them implicit.

4 / 5

Total

19

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents