playbooks

home / skills / pluginagentmarketplace / custom-plugin-typescript / testing

testing skill

/skills/testing

This skill helps you write type-safe TypeScript tests, configure ts-jest and Vitest, and create typed mocks and type-checking test utilities.

npx playbooks add skill pluginagentmarketplace/custom-plugin-typescript --skill testing

Review the files below or copy the command above to add this skill to your agents.

Files (6)
SKILL.md
1.2 KB
---
name: testing
description: TypeScript testing strategies and type-safe test practices
sasmp_version: "1.3.0"
bonded_agent: 08-typescript-tooling-quality
bond_type: PRIMARY_BOND
---

# TypeScript Testing Skill

## Overview
Master TypeScript testing including type-safe test setup, mocking with types, and testing type definitions.

## Topics Covered

### Test Setup
- Jest with ts-jest
- Vitest configuration
- ts-node for tests
- Path alias resolution
- Test coverage with types

### Type-Safe Mocking
- Typed mock functions
- jest.Mocked utility
- vi.fn() typing
- Mock implementations
- Partial mocking

### Type Testing
- tsd for type tests
- expect-type library
- Type assertion tests
- Compile-time testing
- Edge case type testing

### Testing Patterns
- Generic test utilities
- Type-safe fixtures
- Builder patterns for tests
- Custom matchers with types
- Assertion type narrowing

### Integration Testing
- API testing with types
- Database testing
- E2E type safety
- Request/response typing
- Test data factories

## Prerequisites
- TypeScript fundamentals
- JavaScript testing basics

## Learning Outcomes
- Write type-safe tests
- Test type definitions
- Create typed mocks
- Build test utilities

Overview

This skill teaches practical TypeScript testing strategies focused on type-safe test setup, typed mocking, and validating type definitions at compile time. It covers configuration for popular test runners, patterns for reusable test utilities, and techniques to keep tests both robust and type-correct. You will learn to combine runtime assertions with compile-time type checks to surface regressions early.

How this skill works

The skill inspects common test configurations (Jest, Vitest, ts-node) and shows how to wire TypeScript path aliases and coverage while preserving types. It demonstrates typed mock creation using utilities like jest.Mocked and vi.fn(), and introduces compile-time type tests with tools such as tsd and expect-type. Practical patterns include builders, fixtures, and custom matchers that maintain type safety across unit, integration, and E2E tests.

When to use it

  • When setting up Jest or Vitest for a TypeScript project and needing correct source maps and path alias resolution
  • When you want mocks and spies to preserve and enforce original function types
  • When you need to assert library or public API types at compile time to prevent breaking changes
  • When building reusable, type-safe test utilities and fixtures across a codebase
  • When adding type-aware integration or E2E tests that rely on request/response typings

Best practices

  • Prefer compile-time type tests (tsd, expect-type) for public API and type-level assertions
  • Use typed mock helpers (jest.Mocked, Partial<T> patterns, typed vi.fn()) to avoid mismatches
  • Keep test utilities generic and narrowly typed to maximize reuse without sacrificing safety
  • Combine lightweight runtime assertions with type tests to catch both behavioral and typing regressions
  • Configure test runners to preserve TypeScript paths and sourcemaps for clear error traces

Example use cases

  • Validating a library's exported types with tsd to prevent accidental signature changes
  • Building a typed factory/builder for creating consistent test data across unit and integration tests
  • Creating jest.Mocked versions of complex services to assert calls and types in unit tests
  • Configuring Vitest with ts-node and path aliases for fast, type-safe local testing
  • Writing E2E API tests that verify both HTTP responses and their TypeScript response types

FAQ

Can I test types as part of my CI pipeline?

Yes. Run tsd or expect-type checks as a separate CI job to fail builds when public types change unexpectedly.

Should mocks be fully typed or is Partial<T> enough?

Use full jest.Mocked<T> for call/return type safety; Partial<T> is fine for simple stubs but can hide typing issues.