How do I install the Testing skill?

Run npx skillmds@latest add tomevault-io/testing-84 in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Testing safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Testing?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Testing free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Testing?

tomevault-io (@tomevault-io) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Testing by tomevault-io — Agent Skill

Name: Testing
Author: tomevault-io

Testing

Guidelines for running and writing unit and E2E tests. Use this when asked to run tests, write tests, debug test failures, or verify code changes. Also use this before performing any merge commands or pushing code. Use when this capability is needed.

tomevault-io Updated Sep 17, 2026

File contents

Testing Guidelines

Core Philosophy

Test Core Functionality, Not Everything

Focus on critical user paths and essential business logic
Prioritize tests that catch regressions in key features
Avoid over-testing trivial functionality or implementation details
Ask: "If this breaks, will users notice?" - if yes, test it

Tests Must Pass Before Commit/Merge

All existing tests must pass before committing changes
Never skip or disable tests without explicit justification
Broken tests block merges - fix them, don't ignore them
Run the full test suite, not just tests for changed code

Tests Are Production Code

Apply the same code quality standards to tests as production code
Use clear, descriptive names that explain what is being tested
Keep tests maintainable, readable, and well-organized
Include type hints, proper formatting, and meaningful comments
Refactor tests when they become brittle or hard to understand

Running Tests

Always use the provided shell scripts:

# Linux/macOS/Codespaces
./scripts/run-server-tests.sh    # Unit tests (backend)
./scripts/run-e2e-tests.sh       # E2E tests (frontend)

# Windows (PowerShell)
.\scripts\run-server-tests.ps1   # Unit tests (backend)
.\scripts\run-e2e-tests.ps1      # E2E tests (frontend)

These scripts handle environment setup, dependencies, and proper configuration.

Before Creating New Tests

Check existing coverage - avoid duplication
Review existing test patterns - follow established conventions
Identify the right test type - unit for logic, E2E for user flows

Test Quality Standards

Deterministic - Same result every run, no flaky tests
Independent - No dependencies between tests
Fast - Optimize for quick feedback loops
Focused - One logical assertion per test
Descriptive - Test names should read like specifications

Pre-Commit Checklist

Run unit tests: ./scripts/run-server-tests.sh (or .\scripts\run-server-tests.ps1 on Windows)
Run E2E tests (if UI changed): ./scripts/run-e2e-tests.sh (or .\scripts\run-e2e-tests.ps1 on Windows)
Verify new functionality has appropriate test coverage
Confirm no tests were broken or skipped

Converted and distributed by TomeVault — claim your Tome and manage your conversions.

---name: testing-84description: Guidelines for running and writing unit and E2E tests. Use this when asked to run tests, write tests, debug test failures, or verify code changes. Also use this before performing any merge commands or pushing code. Use when this capability is needed.---# Testing Guidelines## Core Philosophy### Test Core Functionality, Not Everything- Focus on critical user paths and essential business logic- Prioritize tests that catch regressions in key features- Avoid over-testing trivial functionality or implementation details- Ask: "If this breaks, will users notice?" - if yes, test it### Tests Must Pass Before Commit/Merge- All existing tests must pass before committing changes- Never skip or disable tests without explicit justification- Broken tests block merges - fix them, don't ignore them- Run the full test suite, not just tests for changed code### Tests Are Production Code- Apply the same code quality standards to tests as production code- Use clear, descriptive names that explain what is being tested- Keep tests maintainable, readable, and well-organized- Include type hints, proper formatting, and meaningful comments- Refactor tests when they become brittle or hard to understand## Running Tests**Always use the provided shell scripts:**```bash# Linux/macOS/Codespaces./scripts/run-server-tests.sh # Unit tests (backend)./scripts/run-e2e-tests.sh # E2E tests (frontend)# Windows (PowerShell).\scripts\run-server-tests.ps1 # Unit tests (backend).\scripts\run-e2e-tests.ps1 # E2E tests (frontend)```These scripts handle environment setup, dependencies, and proper configuration.## Before Creating New Tests1. **Check existing coverage** - avoid duplication2. **Review existing test patterns** - follow established conventions3. **Identify the right test type** - unit for logic, E2E for user flows## Test Quality Standards- **Deterministic** - Same result every run, no flaky tests- **Independent** - No dependencies between tests- **Fast** - Optimize for quick feedback loops- **Focused** - One logical assertion per test- **Descriptive** - Test names should read like specifications## Pre-Commit Checklist1. Run unit tests: `./scripts/run-server-tests.sh` (or `.\scripts\run-server-tests.ps1` on Windows)2. Run E2E tests (if UI changed): `./scripts/run-e2e-tests.sh` (or `.\scripts\run-e2e-tests.ps1` on Windows)3. Verify new functionality has appropriate test coverage4. Confirm no tests were broken or skipped---> Converted and distributed by [TomeVault](https://tomevault.io/claim/geektrainer) — claim your Tome and manage your conversions.

Frequently asked questions