Tooling for writing, managing, and debugging unit and integration tests within the tldraw codebase.
Install
mkdir -p .claude/skills/write-unit-tests && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/703" && unzip -o skill.zip -d .claude/skills/write-unit-tests && rm skill.zipInstalls to .claude/skills/write-unit-tests
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Writing unit and integration tests for the tldraw SDK. Use when creating new tests, adding test coverage, or fixing failing tests in packages/editor or packages/tldraw. Covers Vitest patterns, TestEditor usage, and test file organization.Key capabilities
- →Create unit and integration tests
- →Simulate pointer and keyboard events
- →Assert state machine transitions
- →Mock dependencies with vi.spyOn
- →Manage fake timers for animations
How it works
The skill uses Vitest and the TestEditor class to simulate user interactions and assert expected editor states within the tldraw SDK.
Inputs & outputs
When to use write-unit-tests
- →Write unit tests
- →Improve test coverage
- →Debug failing tests
- →Configure Vitest patterns
About this skill
Writing tests
Unit and integration tests use Vitest and run from workspace directories, not the repo root.
Read a neighboring test before writing a new one — the existing suites are the specification for how we test, and they stay current in a way prose can't. Good starting points:
packages/tldraw/src/test/SelectTool.test.ts— tool state machine assertionspackages/tldraw/src/test/resizing.test.ts— pointer-driven interaction with handlespackages/tldraw/src/lib/shapes/arrow/ArrowShapeUtil.test.ts— shape util plus bindingspackages/editor/src/lib/editor/managers/ClickManager/ClickManager.test.ts— a UI-free managerpackages/editor/src/lib/primitives/Vec.test.ts— a plain primitive
For the available TestEditor methods, read the class itself rather than a list here: packages/tldraw/src/test/TestEditor.ts.
Which workspace
packages/editor— core primitives, geometry, managers, base editor behavior that must not depend on default shapes or UI.packages/tldraw— anything needing default shapes or tools, which is most integration tests.
Each package has its own TestEditor, and they are not interchangeable: packages/editor/src/lib/test/TestEditor.ts has no default shapes or tools, packages/tldraw/src/test/TestEditor.ts wires up the full SDK. Import from the package you're testing in.
cd packages/tldraw && yarn test run
cd packages/tldraw && yarn test run --grep "SelectTool"
cd packages/tldraw && yarn test # watch mode
Placement
Unit tests sit next to the file they cover (Vec.ts → Vec.test.ts). Cross-cutting integration tests live in packages/tldraw/src/test/. Shape and tool tests sit with the implementation, not in src/test/.
Gotchas
These are the things reading an existing test won't tell you.
Wheel and pinch events are batched. dispatch() alone won't apply them — emit a tick to flush:
editor.dispatch(wheelEvent)
editor.emit('tick', 16)
See packages/editor/src/lib/editor/Editor.test.ts for the full pattern.
toCloselyMatchObject is ours, not Vitest's. Use it instead of toMatchObject whenever floating-point geometry is involved, or tests fail on rounding noise. It takes an optional roundToNearest. Defined in packages/tldraw/src/test/TestEditor.ts.
Animation-dependent code needs the rAF stub. vi.useFakeTimers() alone isn't enough, because requestAnimationFrame isn't driven by the fake clock. Tests that animate replace it at module scope — see the top of packages/tldraw/src/lib/shapes/arrow/ArrowShapeUtil.test.ts.
Dispose the editor in afterEach. editor?.dispose() releases the reactive subscriptions and timers the editor holds; without it they leak across tests in the same file. Suites that build up shapes also tend to clear them in beforeEach so each test starts from a known page.
Always mockRestore() a vi.spyOn on the editor. Editor instances outlive individual assertions within a suite, so an unrestored spy silently changes later tests.
Conventions
- Use
createShapeId()for shape IDs so they're stable and typed. - Prefer comparing whole objects over field-by-field assertions when it gives a clearer failure.
- Use
editor.expectToBeIn('select.idle')for state machine assertions rather than reaching into internals. @ts-expect-erroris the way to assert that invalid props are rejected at the type level.
When not to use it
- →When testing outside of workspace directories
Prerequisites
Limitations
- →Tests must run from workspace directories
- →Requires TestEditor for integration tests
How it compares
It provides a dedicated testing harness for tldraw that handles complex editor state and shape lifecycle management automatically.
Compared to similar skills
write-unit-tests side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| write-unit-tests (this skill) | 5 | 3mo | Review | Intermediate |
| vitest | 41 | 6mo | No flags | Intermediate |
| javascript-testing-patterns | 3 | 4mo | Review | Beginner |
| testing-patterns | 3 | 6mo | Review | Beginner |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by tldraw
View all by tldraw →You might also like
vitest
antfu
Vitest fast unit testing framework powered by Vite with Jest-compatible API. Use when writing tests, mocking, configuring coverage, or working with test filtering and fixtures.
javascript-testing-patterns
wshobson
Implement comprehensive testing strategies using Jest, Vitest, and Testing Library for unit tests, integration tests, and end-to-end testing with mocking, fixtures, and test-driven development. Use when writing JavaScript/TypeScript tests, setting up test infrastructure, or implementing TDD/BDD workflows.
testing-patterns
davila7
Jest testing patterns, factory functions, mocking strategies, and TDD workflow. Use when writing unit tests, creating test factories, or following TDD red-green-refactor cycle.
unit-testing-test-generate
sickn33
Generate comprehensive, maintainable unit tests across languages with strong coverage and edge case focus.
designing-tests
CloudAI-X
Designs and implements testing strategies for any codebase. Use when adding tests, improving coverage, setting up testing infrastructure, debugging test failures, or when asked about unit tests, integration tests, or E2E testing.
generate
alirezarezvani
Generate Playwright tests. Use when user says "write tests", "generate tests", "add tests for", "test this component", "e2e test", "create test for", "test this page", or "test this feature".