core-testing
Standardizes testing conventions for unit, integration, and E2E coverage.
Install
mkdir -p .claude/skills/core-testing && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/10426" && unzip -o skill.zip -d .claude/skills/core-testing && rm skill.zipInstalls to .claude/skills/core-testing
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.
Apply Envilder testing conventions for Vitest unit tests and LocalStack e2e tests. Use when adding or updating tests for command handlers, domain entities, adapters, CLI, or GitHub Action flows.Key capabilities
- →Apply AAA testing patterns
- →Implement mocked port contracts
- →Write unit tests
- →Write integration tests
- →Write e2e tests with LocalStack
How it works
It enforces AAA (Arrange, Act, Assert) patterns, naming conventions, and mock boundaries for application handlers and domain logic.
Inputs & outputs
When to use core-testing
- →Writing domain unit tests
- →Adding integration tests
- →Building e2e tests with LocalStack
About this skill
Envilder Testing Conventions
Outcome
Produce tests that match Envilder standards for naming, structure, and confidence level across unit, integration, and e2e coverage.
When To Use
- Adding tests for new application handlers or domain behavior
- Updating tests after refactors in CLI, GHA, infrastructure, or ports
- Reviewing whether test style is consistent before opening a PR
Inputs
- Target behavior, file, or feature to test
- Test level: unit, integration, or e2e
- Any error paths or edge conditions to validate
Procedure
- Classify the test level and strategy.
- Use unit tests by default for domain/application logic.
- Use mocked port contracts (
vi.fn()) for application handlers. - Use e2e tests only when real AWS SSM behavior must be validated.
- Create test files in the matching test tree.
- App and domain tests:
tests/mirrored tosrc/structure. - E2E tests:
e2e/using LocalStack/TestContainers.
- App and domain tests:
- Name tests using the required pattern.
Should_<Expected>_When_<Condition>- Example:
Should_ThrowError_When_SSMParameterIsNotFound
- Write tests with explicit AAA sections.
- Add comment markers in each test block:
// Arrange// Act// Assert
- Each marker appears at most once per test. If you need to test two actions or two assertions on different behaviors, write two separate tests.
- Add comment markers in each test block:
- Mock at the port boundary for application tests.
- Build test doubles by implementing domain port interfaces.
- Prefer
vi.fn()to control behavior and assertions.
- Validate primary success and failure paths.
- Success path (expected output/state change)
- Domain error path (invalid input, missing parameter, etc.)
- Empty/no-op behavior where relevant
- Keep assertions behavior-focused.
- Assert effects and interactions, not implementation details.
- Verify calls to injected ports and logger where behavior requires it.
- Run verification commands before completion.
pnpm testpnpm lint- For CI parity when needed:
pnpm test:ci
Decision Points
- If business rule is pure and deterministic: test at domain layer first.
- If orchestration calls multiple ports: test command handler with mocked dependencies.
- If AWS integration semantics are the risk: add or update e2e with LocalStack.
- Require e2e only when behavior changes cannot be proven confidently with unit tests.
- If only formatting/import changes occurred: update tests only when behavior changed or snapshots/assertions became stale.
Completion Criteria
- Test names follow
Should_<Expected>_When_<Condition> - AAA markers are present, clear, and appear at most once each per test
- Positive and negative paths are both covered
- No mandatory coverage percentage threshold is enforced by this skill
- Tests run green locally with
pnpm test - No type/lint regressions from test changes (
pnpm lint)
Quick Prompt Examples
- "Use testing-conventions for
PullSecretsToEnvCommandHandlerand add missing error-path tests." - "Apply testing-conventions to review
tests/envilder/apps/gha/entry/Gha.test.tsfor naming and AAA compliance." - "Use testing-conventions to design e2e coverage for SSM not-found behavior."
Anti-Pattern: Duplicate Act/Assert Blocks
Wrong: two Acts and Asserts in one test:
it('Should_HandleParameters_When_Called', async () => {
// Arrange
const mockData = { KEY: '/ssm/path' };
// Act
await handler.handle(commandA);
// Assert
expect(mockStore.saveEnvironment).toHaveBeenCalledOnce();
// Act
await handler.handle(commandB);
// Assert
expect(mockStore.saveEnvironment).toHaveBeenCalledTimes(2);
});
Correct: split into two focused tests:
it('Should_SaveEnvironment_When_CommandAProvided', async () => {
// Arrange
const mockData = { KEY: '/ssm/path' };
// Act
await handler.handle(commandA);
// Assert
expect(mockStore.saveEnvironment).toHaveBeenCalledOnce();
});
it('Should_SaveEnvironment_When_CommandBProvided', async () => {
// Arrange
const mockData = { KEY: '/ssm/path' };
// Act
await handler.handle(commandB);
// Assert
expect(mockStore.saveEnvironment).toHaveBeenCalledOnce();
});
When not to use it
- →Testing pure formatting changes
Limitations
- →Requires manual AAA marker placement
- →Requires LocalStack for e2e tests
How it compares
This provides a strict, standardized testing framework compared to ad-hoc test writing.
Compared to similar skills
core-testing side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| core-testing (this skill) | 0 | 3mo | No flags | Intermediate |
| dependency-upgrade | 26 | 5mo | Review | Intermediate |
| woocommerce-dev-cycle | 5 | 3mo | No flags | Intermediate |
| lint-and-validate | 6 | 6mo | Review | Beginner |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by macalbert
View all by macalbert →You might also like
dependency-upgrade
wshobson
Manage major dependency version upgrades with compatibility analysis, staged rollout, and comprehensive testing. Use when upgrading framework versions, updating major dependencies, or managing breaking changes in libraries.
woocommerce-dev-cycle
woocommerce
Run tests, linting, and quality checks for WooCommerce development. Use when running tests, fixing code style, or following the development workflow.
lint-and-validate
davila7
Automatic quality control, linting, and static analysis procedures. Use after every code modification to ensure syntax correctness and project standards. Triggers onKeywords: lint, format, check, validate, types, static analysis.
coverage
alirezarezvani
Analyze test coverage gaps. Use when user says "test coverage", "what's not tested", "coverage gaps", "missing tests", "coverage report", or "what needs testing".
verify-translator
zotero
Steps that MUST be performed to verify a Zotero translator after every addition or modification, and before submitting a PR.
langfuse-core-workflow-b
jeremylongshore
Execute Langfuse secondary workflow: Evaluation and scoring. Use when implementing LLM evaluation, adding user feedback, or setting up automated quality scoring for AI outputs. Trigger with phrases like "langfuse evaluation", "langfuse scoring", "rate llm outputs", "langfuse feedback", "evaluate ai responses".