agentsclimarketplace

Build tests

Skill YoniChechik/claude-code-config/skills/build-tests

Personal Claude Code configuration (hooks, commands, agents, settings).

Install
npx -y skills add YoniChechik/claude-code-config --skill build-tests

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

Plan and build tests for the current feature

SKILL.md

2.2 KB, 449 tokens by cl100k_base, as published. Nobody here has run it

Build Tests Mode

Plan and build tests for the current feature branch.

Additional test focus

"$ARGUMENTS"

If provided, the above gives optional extra constraints or focus areas for test planning. By default, the skill plans and builds tests for all current branch changes without needing any arguments.

Process

Use a subagent to carry out the following 2 phases sequentially:

Phase 1: Test Planning

  • Read the plan file (plan-*.md) in the current working directory to understand what was built and why
  • Read the implementation code — explore all files changed on this branch
  • Run git diff origin/main...HEAD to see all changes
  • Produce a test plan covering:
    • What modules/functions/classes need testing
    • What behaviors and edge cases to cover
    • What integration points to verify
    • What NOT to mock (and why)
    • What testing approach for each component (unit vs integration vs E2E)

Phase 2: Test Building

Write tests following the test plan from Phase 1. Run all tests and fix any failures before finishing.

Mocking Rules — CRITICAL

Unit tests — mocks are fine:

  • Mocks are the standard way to isolate the unit under test. Use them to stub dependencies so you can test one module in isolation.
  • NEVER mock the code under test itself — that defeats the purpose.
  • Keep mocks focused: if you need more than 2-3 mocks in a single test, the design may need rethinking.

Integration tests — NO mocks:

  • Wire real components together. The whole point is verifying that real modules work as a system.
  • Use real instances of data structures, models, and value objects.
  • Invest in proper test fixtures and factories instead of mocking to avoid setup.
  • The ONLY acceptable exceptions: external services (APIs, network calls), time/randomness, slow/flaky third-party libs.

General rules:

  • Integration tests are the bulk of the test suite — they catch the bugs that matter most.
  • Unit tests complement them for fast feedback on isolated logic.
  • E2E tests: few but critical — verify complete user-facing workflows.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Keep looking

Skills are one crate of 327,069. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.