Testing

Skill dewitt4/claude-code-template/.claude/skills/testing

Use this template to launch a Claude Code development workflow with project plan, skills, plug-ins, and MCP servers

Install

npx -y skills add dewitt4/claude-code-template --skill testing

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
0 stars0 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

Generate comprehensive test cases, improve test coverage, and create testing strategies for unit, integration, and e2e tests

SKILL.md

3.4 KB, 773 tokens by cl100k_base, as published. Nobody here has run it

Testing Skill

When working on testing tasks, follow these guidelines:

Test Generation Approach

1. Understand the Code

Analyze the function/module to be tested
Identify inputs, outputs, and side effects
Note dependencies and external interactions
Understand the business logic and requirements

2. Test Categories

Unit Tests

Test individual functions/methods in isolation
Mock external dependencies
Focus on single responsibility
Fast execution

Integration Tests

Test component interactions
Use real or test doubles for dependencies
Verify data flow between modules
Test API endpoints with actual calls

End-to-End Tests

Test complete user workflows
Use real or staging environment
Validate from user perspective
Cover critical business paths

3. Test Coverage

Ensure tests cover:

Happy Path: Normal, expected inputs and flows
Edge Cases: Boundary values, empty inputs, maximum values
Error Cases: Invalid inputs, missing data, exceptions
State Changes: Before/after state verification
Side Effects: Database changes, API calls, file operations

4. Test Structure (AAA Pattern)

// Arrange: Set up test data and conditions
// Act: Execute the code under test
// Assert: Verify the results

5. Best Practices

Clear Names: Test names should describe what's being tested and expected behavior
- Format: test_[method]_[scenario]_[expectedResult]
- Example: test_calculateTotal_withDiscount_returnsReducedAmount
One Assert Per Test: Each test should verify one behavior
Independent Tests: Tests should not depend on each other
Fast Tests: Keep unit tests fast (< 100ms)
Reliable Tests: No flaky tests, no random data without seeds
Maintainable: Easy to understand and update

6. Testing Frameworks

Adapt to the project's testing framework:

JavaScript/TypeScript: Jest, Mocha, Vitest, Cypress
Python: pytest, unittest, nose2
Java: JUnit, TestNG, Mockito
C#: NUnit, xUnit, MSTest
.NET: xUnit, NUnit
Go: testing package, testify
Ruby: RSpec, Minitest

7. Mocking Strategy

Mock external dependencies (APIs, databases, file system)
Use test doubles appropriately:
- Mocks: Verify interactions
- Stubs: Provide predetermined responses
- Fakes: Simplified working implementations
- Spies: Record information about calls

8. Output Format

When generating tests, provide:

Test file location and name
Necessary imports and setup
Complete test cases with:
- Descriptive names
- Arrange/Act/Assert sections
- Comments explaining complex scenarios
Coverage summary: What's tested, what's not
Running instructions: How to execute tests

Code Coverage Goals

Minimum: 70% overall coverage
Target: 80%+ for critical business logic
Focus: Quality over quantity - meaningful tests, not just coverage numbers

When Improving Existing Tests

Analyze current coverage: Identify gaps
Review existing tests: Check for anti-patterns
Prioritize: Start with critical paths and low-coverage areas
Refactor: Make tests more maintainable
Document: Add comments for complex test scenarios

Gives 0 of the 12 instructions most test skills give in 773 tokens

Counted across 964 of the 1,571 authors here whose files we hold, read 2026-08-06

close the browser when donein 55 of 964, across 12 files
wait for network idle statein 51 of 964, across 6 files
launch chromium in headless modein 49 of 964, across 6 files
use descriptive selectors for elementsin 49 of 964, across 6 files
run provided scripts with help flag firstin 49 of 964, across 6 files
add appropriate explicit waitsin 48 of 964, across 5 files
use bundled scripts as black boxesin 46 of 964, across 3 files
do not read script source codein 46 of 964, across 3 files
use sync playwright for scriptsin 46 of 964, across 3 files
inspect dom before executing actionsin 46 of 964, across 3 files
run the full test suitein 36 of 964, across 34 files
write the failing test firstin 25 of 964, across 18 files

Said here and by no other author read

analyze the function or module to be tested
isolate functions in unit tests
test component interactions in integration tests
verify state changes and side effects
adapt to the project testing framework

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.