skills.rest
leonardoacosta
leonardoacostaCOMMUNITY
Explore all skills by this author →
GitHub

t3-testing-patterns

Defines Vitest and Playwright testing standards for T3 Turbo monorepos with fail-closed E2E target validation.

Updated Aug 2, 2026
Search Tags:#vitest#playwright#e2e testing#test fixtures#t3 stack#ci pipeline#flake triage
One-click install
npx skills add https://github.com/leonardoacosta/skills --skill t3-testing-patterns-leonardoacosta
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: t3-testing-patterns
Source: https://github.com/leonardoacosta/skills/tree/main/t3-stack-kit/skills/t3-testing-patterns
Command: npx skills add https://github.com/leonardoacosta/skills --skill t3-testing-patterns-leonardoacosta

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Writing reliable tests in a T3 Turbo monorepo is hard: teams mock away the database and prove nothing, E2E runs silently fall back to localhost or hit production, shared auth state causes flakes, and retry-passes get counted as clean evidence. This Skill encodes enforceable standards for unit, integration, and Playwright E2E testing so runs are deterministic, isolated, and auditable. ## Core Features & Use Cases - Unit and integration rules: Use a real migrated Postgres for Drizzle/tRPC tests via createCaller and typed context builders, with narrow typed provider fakes instead of SDK mocks. - Fail-closed E2E target validation: Enforce exact test:e2e/test:e2e:local commands, a private short-lived run capability binding mode, URL, and non-production identities, and a strict canonical/local/CI/collection mode matrix. - Fixtures, personas, and mutation ownership: Isolated persona storage state with 0700/0600 permissions, server-derived mutation ownership, authorize-before-update/delete, and child-first cleanup with escaped-record checks. - Topology and evidence: Exact Chromium completeness collection, native sharding with setup-once --no-deps, quarantine metadata, retry/flake classification, artifact secret scanning, and worker benchmark gates. - Use Case: A CI job proposes fullyParallel: true with eight workers on a mutation-heavy suite sharing an admin storageState. The Skill requires serial one-worker defaults until narrow ownership, isolated personas, clean cleanup, and two adjacent clean benchmark runs prove concurrency is safe. ## Quick Start Ask the agent to review your Playwright E2E configuration and test suite against these T3 testing standards before enabling parallelism or adding a CI lane.

Frequently Asked Questions about t3-testing-patterns

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
Should I mock the Drizzle database module in Vitest tests?▼

No. Database query, migration, constraint, and tenant-isolation tests must run against a real migrated test Postgres, because mocking the Drizzle module only proves the mock's behavior. Pure validators and formatters may use ordinary fakes.

How do I run Playwright E2E tests against a local server in a T3 monorepo?▼

Use the exact root command `pnpm test:e2e:local`, which is loopback-only and requires non-production database and service identities. The canonical `pnpm test:e2e` command targets deployed HTTPS non-production environments only; there is no silent localhost fallback.

Can Playwright use BASE_URL as a fallback when E2E_BASE_URL is missing?▼

No. `BASE_URL` is migration guidance only and is never accepted as runtime input. A missing, malformed, or credential-bearing `E2E_BASE_URL` fails validation before Playwright collection or config import runs.

When can I enable fullyParallel and multiple workers for mutation E2E tests?▼

Only after every mutation has narrow server-derived ownership, personas use isolated contexts, cleanup and escaped-record checks are clean, and two adjacent clean full-suite unsharded benchmark runs pass at the same target class. A separate database per lane alone is not proof.

Why do my Playwright sign-in tests return 429 on preview deployments?▼

Auth 429s under higher worker counts usually indicate rate limiting, shared persona sessions, or capacity issues rather than app bugs. Check the Better Auth rate-limiting scoping reference, isolate persona storage state, and compare database connections against configured limits before raising workers.

Does a Playwright test that passes on retry count as clean benchmark evidence?▼

No. A retry pass is always classified as flaky through machine-readable post-run classification. Clean benchmark evidence requires no initial failure, no missing artifacts, no quarantine regression, and no cleanup or provider escapes.

Related Skills

Explore More Software Engineering Skills→
leonardoacostaleonardoacosta

frontend-api-contracts

Designs tRPC procedure contracts with Drizzle query shapes for T3 Turbo monorepos.

Community
Intermediate
rabbicserabbicse

test-reliability

Diagnose and repair flaky Playwright end-to-end tests at runtime.

Community
Advanced
testdoubletestdouble
198

tdd

Enforce a red-green-refactor TDD loop with failing tests before production code changes.

Official
Advanced
factorialcofactorialco
27

f0-storybook-testing

Automate interaction and accessibility tests for Storybook components with Playwright and axe-playwright.

Official
Intermediate