typescript-fake-driven-testing

Guides TypeScript test architecture using gateway interfaces, in-memory fakes, and scenario tests.

2|Updated Apr 2, 2026
One-click install
npx skills add https://github.com/nseng-ai/ns --skill typescript-fake-driven-testing-nseng-ai
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: typescript-fake-driven-testing
Source: https://github.com/nseng-ai/ns/tree/main/skills/internal/typescript/typescript-fake-driven-testing
Command: npx skills add https://github.com/nseng-ai/ns --skill typescript-fake-driven-testing-nseng-ai

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? TypeScript codebases that depend on external systems like git, subprocesses, filesystems, and networks are hard to test without slow integration suites or brittle mocks. This Skill provides a consistent architecture for writing and reviewing testable TypeScript code using semantic gateways and in-memory fakes. ## Core Features & Use Cases - Gateway Design Rules: Defines capability-shaped gateway interfaces for external and non-deterministic dependencies, with naming conventions and anti-pattern guidance. - Fake-Driven Testing: Prescribes constructor-state in-memory fakes that implement the same gateway types as real adapters, replacing scripted mocks and module spies. - Layered Test Strategy: Separates unit, gateway, scenario, and integration test layers with clear rules for what each layer asserts. - Use Case: When reviewing a pull request that adds a CLI calling git and a deployment API, apply this Skill to verify the diff defines proper gateways, uses result unions for expected failures, and tests through the public entry point with in-memory fakes. ## Quick Start Review this TypeScript diff against the fake-driven testing architecture and flag any gateway, fake, or test-layer violations.

Frequently Asked Questions about typescript-fake-driven-testing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
When should I avoid the gateway and fake testing pattern?

Pure helpers and policy functions with no gateways or I/O belong in plain unit tests and need no fakes. Integration tests that verify real git, filesystem, or process compatibility should retain actual external systems rather than fakes.