typescript-testing

Enforces mandatory Vitest testing conventions for TypeScript CLI, SDK, website, and CDK stacks.

138|5|Updated Sep 19, 2024
One-click install
npx skills add https://github.com/macalbert/envilder --skill typescript-testing-macalbert
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: typescript-testing
Source: https://github.com/macalbert/envilder/tree/main/.github/skills/typescript-testing
Command: npx skills add https://github.com/macalbert/envilder --skill typescript-testing-macalbert

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? TypeScript projects with multiple stacks (CLI, SDK, website, CDK infrastructure) often suffer from inconsistent test styles, unclear naming, and mixed assertion patterns that make tests hard to read and maintain. This Skill enforces a single mandatory set of testing conventions so every test follows the same structure. ## Core Features & Use Cases - AAA Pattern Enforcement: Requires Arrange-Act-Assert markers in every test, with strict rules against combined Act & Assert blocks, conditionals, or try/catch inside tests. - Naming and Variable Standards: Mandates the Should_{ExpectedBehavior}_When_{Condition} test naming format and fixed variable names like sut, actual, and expected. - Stack-Specific Templates: Provides ready-to-use Vitest test structures for CLI/Core handlers with InversifyJS, Node.js SDK clients, CDK infrastructure assertions, and E2E tests with TestContainers. - Use Case: When writing a unit test for a new command handler, apply this Skill to generate a properly structured Vitest suite with mocked ports, correct exception testing, and compliant naming. ## Quick Start Write a Vitest unit test for the PullSecretsToEnvCommandHandler following the mandatory AAA pattern and naming conventions.

Frequently Asked Questions about typescript-testing

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

FAQPage Schema
How do I write Vitest tests following the AAA pattern?

Structure every test with // Arrange, // Act, and // Assert comments, each appearing at most once. Keep Act to a single invocation on the system under test, place all expect() calls only in Assert, and never combine Act and Assert into one block.

What naming convention should Vitest test names follow?

Test names must follow the format Should_{ExpectedBehavior}_When_{Condition} in PascalCase, such as Should_ThrowError_When_SSMParameterIsNotFound. Vague names like Should_Work or missing When clauses are not allowed.

How do I test exceptions in Vitest without mixing Act and Assert?

Wrap the throwing call in a function during Act, then assert in Assert: const act = () => createProvider(config); expect(act).toThrow(Error). For async code, use await expect(act).rejects.toThrow() with the promise created in Act.

Can I use conditionals or try/catch inside Vitest test bodies?

No. If, switch, and try/catch/finally are forbidden inside Arrange, Act, or Assert. Split branching scenarios into separate tests and use beforeEach/afterEach hooks for setup and teardown logic.

How do I mock dependencies in Vitest for handler tests?

Create port test doubles as plain objects with vi.fn() methods matching the interface, then control behavior with vi.mocked(mock.fn).mockResolvedValue() or mockRejectedValue(). Verify interactions with toHaveBeenCalledWith and toHaveBeenCalledTimes.