Power Setup Comprehensive Testing

Power Setup Comprehensive Testing is a command that establishes a full multi-layer testing infrastructure for your project in a single execution, spanning unit tests, integration tests, end-to-end tests, and specialized testing categories like visual regression and performance benchmarks. It designs a testing strategy aligned with the testing pyramid, installs and configures all necessary frameworks, creates example tests for each layer, and wires everything into your CI/CD pipeline with appropriate quality gates and parallelization.

When to Use This Command

Run this command when...

• You are starting a greenfield project and want to establish testing infrastructure correctly from day one, covering all testing layers with proper tooling.
• Your existing project has grown organically with ad-hoc testing and needs a structured overhaul that introduces missing testing layers and standardizes existing ones.
• You are migrating to a new tech stack and need to rebuild the entire testing infrastructure to match the new framework and language requirements.
• Leadership has mandated comprehensive quality gates and you need to implement a complete testing pipeline that enforces coverage, mutation scores, and performance budgets.
• The team is expanding and you need standardized testing practices, conventions, and infrastructure that new developers can follow immediately.

Consider alternatives when...

• You only need a single testing layer added (e.g., just E2E tests); use the specific setup command for that layer instead.
• Your project is a small script or utility that only warrants unit tests; the overhead of a multi-layer setup is not justified.
• You are in an exploratory phase where requirements are changing rapidly and investing in comprehensive testing infrastructure would be premature.

Quick Start

Copy
# testing-infrastructure.yml
project:
  type: fullstack
  language: typescript
  frameworks: [react, express]
layers:
  unit:
    framework: vitest
    coverage_target: 80
  integration:
    framework: vitest
    database: postgres_testcontainers
  e2e:
    framework: playwright
    browsers: [chromium, firefox]
  visual:
    tool: playwright_screenshots
  performance:
    tool: lighthouse_ci
    budgets: true
ci:
  provider: github-actions
  parallel: true
  quality_gates: true

Example invocation:

Copy
power-setup-comprehensive-testing "typescript fullstack with react and express"

Example output:

Comprehensive Testing Infrastructure Complete
-----------------------------------------------
Project Type:   Full-stack TypeScript (React + Express)
Layers:         5 testing layers configured

Unit Testing:
  Framework:    Vitest v1.6
  Config:       vitest.config.ts
  Example:      src/__tests__/example.unit.test.ts
  Coverage:     v8 provider, 80% threshold

Integration Testing:
  Framework:    Vitest + Supertest
  Database:     Testcontainers (PostgreSQL)
  Example:      src/__tests__/example.integration.test.ts

E2E Testing:
  Framework:    Playwright v1.44
  Browsers:     Chromium, Firefox
  Config:       playwright.config.ts
  Example:      e2e/example.spec.ts

Visual Testing:
  Tool:         Playwright screenshot comparison
  Baseline:     e2e/visual-baselines/

Performance Testing:
  Tool:         Lighthouse CI
  Config:       lighthouserc.json
  Budgets:      FCP < 1.8s, LCP < 2.5s, CLS < 0.1

CI Pipeline:
  File:         .github/workflows/testing.yml
  Stages:       lint -> unit -> integration -> e2e -> visual -> perf
  Quality Gate: All stages must pass for merge

Core Concepts

Concept	Purpose	Details
Testing Pyramid	Guides the proportion of tests at each layer	Many fast unit tests at the base, fewer integration tests in the middle, and a small number of slow E2E tests at the top; this optimizes feedback speed and maintenance cost
Quality Gate	Enforces minimum standards before code can merge	A CI check that blocks pull requests when test coverage drops below thresholds, tests fail, or performance budgets are exceeded
Test Isolation	Prevents tests from interfering with each other	Each test runs in its own environment with independent data, database state, and browser context to eliminate flaky cross-test contamination
Parallel Pipeline	Reduces total CI execution time	Runs independent testing layers concurrently on separate CI machines; unit tests do not wait for E2E tests to complete before reporting
Coverage Composition	Aggregates coverage data across layers	Combines coverage reports from unit, integration, and E2E layers into a unified view showing which code is tested by which layer

     Power Setup Comprehensive Testing Architecture
  +--------------------------------------------------------------+
  |  CI/CD PIPELINE                                              |
  |  Trigger --> Lint --> [Parallel Test Execution] --> Gate      |
  +--------------------------------------------------------------+
       |                |              |            |          |
       v                v              v            v          v
  +----------+  +------------+  +---------+  +--------+  +------+
  |  UNIT    |  | INTEGRATION|  |  E2E    |  | VISUAL |  | PERF |
  |  vitest  |  |  vitest+   |  |playwright| |  pixel |  | LH   |
  |  fast    |  |  supertest |  |  browser |  |  diff  |  | CI   |
  |  ~80%    |  |  testcont. |  |  flows   |  | check  |  | budg |
  +----------+  +------------+  +---------+  +--------+  +------+
       |                |              |            |          |
       v                v              v            v          v
  +--------------------------------------------------------------+
  |  QUALITY GATE EVALUATION                                     |
  |  Coverage >= 80% | All Pass | No Regressions | Budgets Met   |
  +--------------------------------------------------------------+

Configuration

Parameter	Type	Default	Description
layers	array	[unit, integration, e2e]	Testing layers to set up; options include unit, integration, e2e, visual, performance, and contract
unit_framework	string	auto-detect	Unit testing framework: vitest, jest, pytest, junit, or go_test
coverage_target	integer	80	Minimum code coverage percentage enforced as a quality gate across the unit and integration layers
ci_provider	string	auto-detect	CI/CD platform for pipeline configuration: github-actions, gitlab-ci, jenkins, or circleci
parallel	boolean	true	Whether to run independent testing layers concurrently in CI to reduce total pipeline execution time

Best Practices

1. Respect the testing pyramid proportions even when enthusiasm is high. It is tempting to write many E2E tests because they feel comprehensive, but a pyramid-violating "ice cream cone" shape leads to slow pipelines and high maintenance costs. Target roughly 70% unit tests, 20% integration tests, and 10% E2E tests by count. This distribution maximizes bug detection while keeping feedback loops fast.

2. Set quality gates incrementally rather than at maximum strictness from day one. Starting with 80% coverage thresholds on a codebase that currently has 30% coverage means every pull request will fail the gate. Begin with a threshold just above the current baseline and ratchet it upward over time. Configure the gate to only enforce coverage on new and modified code, allowing legacy code to be improved gradually.

3. Use Testcontainers for integration test database isolation. Rather than maintaining a shared test database that accumulates state across test runs, use Testcontainers to spin up a fresh database instance for each test suite. This eliminates the "works on my machine" problem and ensures CI environments are identical to local development environments. The startup overhead is negligible compared to the debugging time saved from state-related flakiness.

4. Establish naming conventions that make test purpose immediately clear. Use suffixes like .unit.test.ts, .integration.test.ts, and .e2e.spec.ts to distinguish test types at a glance. This also enables running specific layers independently through glob-based test runner configuration. When a CI stage fails, the naming convention tells you immediately which layer has the problem without examining the pipeline logs.

5. Monitor test suite execution time as a first-class metric. A testing infrastructure that takes 45 minutes to run becomes a bottleneck that developers work around rather than work with. Track total pipeline duration, identify the slowest tests, and optimize or restructure them. Set a team-wide SLA for pipeline duration (e.g., under 15 minutes) and treat violations as technical debt requiring immediate attention.

Common Issues

CI pipeline times out because all testing layers run sequentially. The default pipeline configuration may execute layers in series even when they are independent. Verify that the generated CI workflow uses parallel job definitions where layers do not depend on each other. Unit and integration tests can run concurrently, with E2E tests starting only after the application build step completes.

Integration tests fail because the database container cannot start in CI. CI environments sometimes restrict Docker socket access or have resource limits that prevent Testcontainers from launching. Check that the CI runner supports Docker-in-Docker or has a Docker service available. For GitHub Actions, add services: postgres: to the workflow definition as an alternative to Testcontainers when container-in-container is not supported.

Coverage numbers seem low despite having tests for every file. Coverage is measured at the branch level, not just the line level. A function with three if-else branches requires at least four test cases to achieve 100% branch coverage, even though a single test case might execute every line. Examine the coverage report's branch coverage column and add tests specifically targeting uncovered branches rather than adding more tests for already-covered paths.