core-testing

Write Vitest unit, integration, and LocalStack e2e tests following Envilder naming and AAA conventions.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams working on the Envilder codebase need tests that follow a consistent verification contract: correct test level selection, standardized naming, explicit AAA structure, and port-boundary mocking. Without these conventions, test suites drift in style and fail to protect the actual behavioral risks. ## Core Features & Use Cases - Test Level Classification: Chooses between unit tests for pure domain logic, mocked-port tests for command handlers, and integration or e2e tests with LocalStack/TestContainers for cloud, CLI, or GitHub Action wiring risks. - Naming and Structure Enforcement: Applies the Should_<Expected>_When_<Condition> naming pattern and single-use // Arrange, // Act, // Assert markers per test. - Port-Boundary Mocking: Builds test doubles with vi.fn() against domain port interfaces, asserting behavior rather than implementation details. - Use Case: When adding error-path coverage for PullSecretsToEnvCommandHandler, the skill guides you to mock the secret store port, write separate tests per behavior, and validate with pnpm test and pnpm lint. ## Quick Start Ask the AI to apply the core-testing conventions to add missing error-path tests for a specific command handler or test file.

Frequently Asked Questions about core-testing

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

FAQPage Schema
How do I write Vitest tests for a command handler with mocked dependencies?

Implement the domain port interfaces as test doubles using vi.fn() to control behavior and assertions. Inject the mocks into the handler, then assert effects and port interactions rather than internal implementation details.

What test naming convention does Envilder use?

Tests follow the Should_<Expected>_When_<Condition> pattern, for example Should_ThrowError_When_SSMParameterIsNotFound. Each test also contains explicit // Arrange, // Act, and // Assert comment markers, each appearing at most once.

When should I use e2e tests with LocalStack instead of unit tests?

Use e2e tests with LocalStack or TestContainers when AWS integration semantics, DI wiring, CLI, or GitHub Action behavior is the actual risk. Require e2e only when the behavior cannot be proven confidently with unit tests.

Can one test contain multiple Act and Assert blocks?

No. Each AAA marker may appear at most once per test. If you need to verify two actions or two behaviors, split them into separate focused tests, each with its own Arrange, Act, and Assert sections.

When should I not add a new test?

Skip adding tests when a compiler, schema, direct workflow, or existing baseline already protects the requirement. For PURE_REFACTOR intents keep behavioral tests unchanged, and for NON_BEHAVIORAL_CHANGE intents do not manufacture tests.