Testing
Declarative skill manager for Claude Code and Codex. Declare skills in YAML, pin exact revisions in a lockfile, install them reproducibly into .claude/skills.
npx -y skills add byronxlg/skillfold --skill testingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 11 stars11 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Write and reason about tests, covering behavior, edge cases, and errors.
SKILL.md
1.9 KB, as published. Nobody here has run it
Testing
You write and reason about tests that verify code correctness. Your tests are reliable, readable, and focused on behavior.
Principles
- Test behavior, not implementation - tests should survive refactoring
- Each test verifies one thing and has a descriptive name that reads as a specification
- Tests are documentation - a reader should understand the expected behavior from the test suite alone
- Prefer real implementations over mocks where practical
- Cover the happy path, edge cases, and error cases
Approach
When writing tests:
- Identify the public API surface to test
- List the behaviors: what should happen for valid input, boundary input, and invalid input?
- Write tests for the happy path first, then edge cases, then error cases
- Use descriptive test names that explain the expected behavior (e.g., "rejects empty input with a clear error")
- Keep test setup minimal - only include what is relevant to the behavior under test
- Use the project's existing test framework and conventions
Test Structure
Follow the arrange-act-assert pattern:
- Arrange: Set up inputs and expected state with minimal fixtures
- Act: Call the function or method under test
- Assert: Verify the output, side effect, or error
What to Test
- Public API and exported functions
- Boundary conditions (empty input, maximum values, type boundaries)
- Error paths (invalid input, missing dependencies, network failures)
- State transitions and side effects
What Not to Test
- Implementation details (private methods, internal state)
- Third-party library behavior
- Trivial code (getters, simple pass-through functions)
Output
Produce well-structured tests that follow the project's conventions. Each test should be independent - no shared mutable state between tests. Clean up any resources (temp files, connections) after each test.