testing

discountedcookie's avatarfrom discountedcookie

Run tests before and after changes. Only add tests for complex logic, not boilerplate. Database tests matter most.

⭐0stars🔀0forks📁View on GitHub🕐Updated Dec 15, 2025
[Testing and QA]

When & Why to Use This Skill

This Claude skill automates the software testing lifecycle by enforcing a disciplined 'test-before-and-after' workflow. It optimizes development efficiency by focusing on high-impact testing for complex business logic and database functions using pgTAP and Vitest, ensuring code reliability while preventing test bloat and maintaining a lean codebase.

Use Cases

  • Automated Regression Testing: Automatically execute the full test suite before starting a task to establish a stable baseline and rerun it after changes to immediately detect and fix regressions.
  • Database Logic Verification: Utilize pgTAP to rigorously validate complex SQL functions and critical business logic residing in the database layer, ensuring data integrity and backend stability.
  • Smart Test Coverage: Identify and implement targeted test cases for non-obvious edge cases and complex data transformations while intentionally skipping redundant boilerplate tests to keep the CI/CD pipeline fast.
  • Refactoring Safety Net: Provide a reliable safety net during code refactoring by verifying that internal logic changes do not alter expected outcomes through consistent unit and integration testing.
nametesting
description>-

Testing

Verify changes don't break things. Don't create test bloat.

Announce: "I'm running tests to verify the changes."

Philosophy

Database (pgTAP): This is where real logic lives. Test it thoroughly.

Frontend (Vitest): Thin RPC layer. Only test:

  • Complex transformations
  • Non-obvious edge cases
  • NOT: "does this call that function"

Workflow

Before implementing:

bun run test

If tests fail, fix them first.

After implementing:

bun run test

If tests fail, your change broke something. Fix it.

When to Add Tests

YES - add tests for:

  • New database functions with business logic
  • Complex data transformations
  • Non-obvious edge cases you discovered

NO - don't test:

  • "Does this function call that function"
  • Pinia store initialization
  • Vue component mounting
  • API calls with mocked responses
  • Obvious behavior readable from code

Commands

bun run test        # All tests (unit + db)
bun run test:unit   # Frontend only
bun run test:db     # Database only (pgTAP)

If Tests Fail

  1. Read the error message
  2. Check if YOUR change caused it
  3. If yes → fix your code
  4. If no → fix the test or report the issue