project-testing

Consiliency's avatarfrom Consiliency

"Custom test patterns and fixtures for {project}. Covers E2E, integration, and specialized testing requirements."

⭐1stars🔀0forks📁View on GitHub🕐Updated Jan 4, 2026
[Testing and QA]

When & Why to Use This Skill

This Claude skill provides a comprehensive framework for project-specific testing, offering standardized patterns, fixtures, and strategies for Unit, Integration, and E2E testing. It helps developers maintain high code quality by enforcing coverage targets, proper isolation, and consistent naming conventions across the entire testing lifecycle.

Use Cases

  • Standardizing Test Architecture: Implementing a consistent directory structure and naming convention for unit, integration, and E2E tests to improve codebase maintainability.
  • Automating Complex Workflows: Utilizing pre-defined fixtures and browser automation patterns to create reliable E2E tests for full user journeys.
  • Enforcing Quality Standards: Setting and monitoring code coverage targets (e.g., 90% for core logic) and integrating automated checks into CI/CD pipelines.
  • Preventing Flaky Tests: Applying 'Red Flag' logic to ensure proper test isolation and cleanup, reducing false positives in automated testing suites.
name{project}-testing
description"Custom test patterns and fixtures for {project}. Covers E2E, integration, and specialized testing requirements."
generated_byai-dev-kit:recommend-skills

{project} Testing Patterns

Custom testing patterns, fixtures, and strategies for this project.

Variables

Variable Default Description
COVERAGE_TARGET 80 Minimum coverage percentage
E2E_TIMEOUT 30000 E2E test timeout in ms
PARALLEL_TESTS true Run tests in parallel when possible

Instructions

  1. Identify test type needed (unit/integration/e2e)
  2. Use appropriate fixtures and patterns
  3. Follow project naming conventions
  4. Ensure proper cleanup

Red Flags - STOP and Reconsider

If you're about to:

  • Write a test without proper isolation
  • Skip cleanup in fixtures
  • Hardcode test data instead of using fixtures
  • Write flaky tests (timing-dependent, order-dependent)

STOP -> Use proper fixtures -> Ensure isolation -> Then write test

Test Categories

Unit Tests

Location: tests/unit/

Patterns:

  • Test single functions/methods in isolation
  • Mock external dependencies
  • Fast execution (< 100ms each)

Integration Tests

Location: tests/integration/

Patterns:

  • Test component interactions
  • Use test database/fixtures
  • May have external dependencies

E2E Tests

Location: tests/e2e/ or playwright/

Patterns:

  • Test full user workflows
  • Use browser automation
  • Longer execution time acceptable

Fixtures

Database Fixtures

Location: tests/fixtures/

Usage:

# Python example
from tests.fixtures import sample_user, sample_order

def test_order_creation(sample_user, sample_order):
    # Test uses pre-configured fixtures
    pass

Mock Services

Location: tests/mocks/

Available mocks:

  • [TODO: List project-specific mocks]

Naming Conventions

Test Type File Pattern Function Pattern
Unit test_*.py test_<function>_<scenario>
Integration test_*_integration.py test_<component>_<action>
E2E *.spec.ts test('<feature> - <scenario>')

Coverage Requirements

Component Minimum Coverage
Core logic 90%
API routes 80%
Utilities 70%

CI Integration

Tests run in CI:

  • On PR: unit + integration
  • On merge: all including E2E
  • Nightly: full regression suite

Customization

Edit this file to add:

  • New fixture definitions
  • Additional mock services
  • Custom test patterns
  • Coverage exceptions