unit-tests
Guardrails for adding unit tests in bklit-ui without over-testing. Use when the user mentions unit test, unit tests, tests, test coverage, add tests, write tests, vitest, jest, or asks whether something should be tested.
- Installs
- 671
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/bklit/bklit-ui --skill unit-tests- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads unit-tests automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Unit Tests (bklit-ui)
Read this skill before proposing or writing tests. Default stance: fewer, higher-signal tests.
When to add tests
Add tests when they lock in behavior that is easy to break silently:
| Worth testing | Why |
|---|---|
| Pure functions / modules | Stable inputs → outputs; fast; no DOM |
| Formatters, parsers, scale math, bounds | Regression on string/number output is user-visible |
| Codegen / export / registry helpers | Output shape is the contract |
| Non-obvious edge cases | Empty data, reversed ranges, clamping |
Examples in this repo: chart-formatters.test.ts, highlight-segment-bounds.test.ts, animation.test.ts, apps/web/lib/studio/__tests__/*.
When NOT to add tests (unless explicitly requested)
Do not add tests just to increase coverage or “be thorough”:
| Skip | Why |
|---|---|
| React component render smoke tests | visx, motion, portals → brittle; manual/docs check is cheaper |
memo() / guard extractions (#65-style) | Structural perf refactors; output unchanged; RTL mount assertions are heavy |
| Default prop passthrough | formatValue = intFmt — types + formatter tests cover it |
| Third-party library behavior | Don’t re-test d3, visx, or React |
| Trivial getters / one-line wrappers | No regression signal |
| Snapshot entire chart SVG/JSX | High churn, low signal |
If the user asks “should we test X?” — say no when X falls in this table, and suggest a lighter alternative (pure helper test, manual check, CI build).
Repo conventions
Runner: Node built-in test runner + tsx (not Jest/Vitest unless the repo adopts them later).
pnpm test # root — turbo runs packages with a test script
pnpm --filter @bklitui/ui test
cd apps/web && pnpm test
Place tests: **/__tests__/**/*.test.ts next to the code under test.
Pattern:
import assert from "node:assert/strict";
import { describe, it } from "node:test";
import { myFn } from "../my-module";
describe("myFn", () => {
it("handles empty input", () => {
assert.equal(myFn([]), expected);
});
});
Equivalence tests (preferred for formatters): assert shared module output matches the previous inline call (e.g. toLocaleDateString with same locale/options) so tests stay timezone-safe and prove no visual regression.
New package test script: add to package.json:
"test": "node scripts/run-tests.mjs"
Use a small scripts/run-tests.mjs that collects *.test.ts from __tests__ and invokes node --import tsx --test — shell globs break on Linux CI. Add tsx as a devDependency if missing. Wire into root turbo.json test task; CI runs pnpm test.
Decision checklist (run before writing)
- Is the logic pure or extractable to pure functions? → Test that. Consider extracting first.
- Would a test fail on a real user-visible bug? → Good candidate.
- Does it need jsdom / RTL / Playwright? → Stop; justify to user or defer to manual/visual check.
- Did the user ask for tests? → Still apply this skill; don’t over-deliver.
- How many cases? → 3–10 focused cases, not exhaustive matrices.
What to tell the user
When recommending tests, be explicit:
- Add: “Test
chart-formatters.ts— pure, high regression value.” - Skip: “Skip component tests for the memo split — no output change; build + manual chart docs are enough.”
- CI: Mention
pnpm testin PR test plan when adding or changing tests.
Anti-patterns
- Adding Jest/Vitest/Testing Library for a one-off without team buy-in
- Mocking entire chart context to assert
useMemocall counts - Testing implementation details (hook order, internal component names)
- Duplicating type-checker work (
expect(typeof x).toBe('function')) - Committing tests that only pass locally due to hard-coded timezone/locale strings
FAQ
What does the unit-tests skill do?
Guardrails for adding unit tests in bklit-ui without over-testing. Use when the user mentions unit test, unit tests, tests, test coverage, add tests, write tests, vitest, jest, or asks whether something should be tested.
How do I install unit-tests?
Run npx skills add https://github.com/bklit/bklit-ui --skill unit-tests in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/unit-tests/ (personal) or .claude/skills/unit-tests/ (project).
Which AI agents can use unit-tests?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is unit-tests safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains unit-tests?
It is published by bklit in bklit/bklit-ui. It has 671 recorded installs.
More from bklit/bklit-ui
bklit-ui
bklit/bklit-ui
Install, compose, theme, and animate Bklit UI charts (the @bklit shadcn registry) in a React / Next.js app. Use when the user wants a chart, graph, or data visualization: line, area, bar, live/streaming line, composed, scatter, candlestick/OHLC, pie, ring/donut, radar, gauge, heatmap, funnel, sankey, sunburst, or choropleth/world map; a sparkline or tiny inline chart (LineSparkline, AreaSparkline, BarSparkline, useSparklineHover) for tables, KPI cards, or dense dashboards; a dashboard, analytics page, KPI or stat card; chart tooltips, crosshairs, legends, markers, reference bands, projections, trend lines, axes, or grids; or when code imports from components/charts/ or mentions @bklit/ or bklit.com. For styling vocabulary (patterns, squircle/rounded/3D bars, fades, loading looks, matching the app theme) also use bklit-ui-design. For moving from Recharts, shadcn ChartContainer, or TanStack Charts to Bklit, use bklit-ui-migrate.
bklit-studio-chart-performance
bklit/bklit-ui
Reusable Studio chart performance audit and fix workflow. Use when a chart feels sluggish in /studio (pan, slider ticks, legend hover) but siblings like pie-chart feel fine.
turborepo
bklit/bklit-ui
Turborepo monorepo build system guidance. Triggers on: turbo.json, task pipelines, dependsOn, caching, remote cache, the "turbo" CLI, --filter, --affected, CI optimization, environment variables, internal packages, monorepo structure/best practices, and boundaries. Use when user: configures tasks/workflows/pipelines, creates packages, sets up monorepo, shares code between apps, runs changed/affected packages, debugs cache, or has apps/packages directories.
bklit-ship
bklit/bklit-ui
bklit-ui monorepo contributors only — ship a chart or component from Studio prototype to production in packages/ui with docs and registry.
bklit-playground
bklit/bklit-ui
DEPRECATED — use bklit-studio instead. Local /playground is no longer the chart development workflow for bklit-ui contributors.
pr-open
bklit/bklit-ui
Open a pull request the bklit-ui way: stage and commit with pre-commit hooks, run ultracite from the repo root, rebuild the shadcn registry, run a production test build, fix failures, push, and create a PR with a structured summary. Use when the user asks to commit, push, open a PR, "ship it", or run the full pre-PR checklist.
Popular testing & qa skills
tdd
mattpocock/skills
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
grilling
mattpocock/skills
Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
migrate-to-shoehorn
mattpocock/skills
Migrate test files from as type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace as in tests, or needs partial test data.
run-train
lllllllama/rigorpilot-skills
Rigor Train skill for deep learning research repositories. Use when a documented or selected training command should be run conservatively for startup verification, short-run verification, full kickoff, or resume, with command, config, seed, log, checkpoint, status, and metric evidence written to standardized trainoutputs/. Do not use for environment setup, exploratory sweeps, speculative idea implementation, or end-to-end orchestration.
test-driven-development
obra/superpowers
Use when implementing any feature or bugfix, before writing implementation code
finishing-a-development-branch
obra/superpowers
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work