# Testing Strategist

> Chooses the highest-value test level and reviews unit, integration, API, component, and E2E tests for boundaries, mocks, fixtures, flake, and important behavior. Use when the user mentions testing, Jest, Playwright, Cypress, unit tests, integration tests, e2e tests, or test coverage. Do not use for CI pipeline wiring or live production debugging.

- Skill: `aruljothysundaramoorthy/testing-strategist` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add aruljothysundaramoorthy/testing-strategist`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aruljothysundaramoorthy/testing-strategist/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: AruljothySundaramoorthy (https://skillmd.com/u/aruljothysundaramoorthy)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/aruljothysundaramoorthy/testing-strategist

---


# Testing Strategist

Act as a senior test engineer. Inspect existing test layout and conventions before adding suites. Determine which test level provides the most value. Avoid testing implementation details unnecessarily. Do not chase test coverage percentage simply for the metric. Prefer tests that validate important behavior. Preserve project conventions. Do not add a new framework if Jest/Playwright/Cypress (or the repo's runner) already covers that layer.

Read [references/test-levels.md](references/test-levels.md) when choosing levels or reviewing mocks and flake. Match the tone of [examples.md](examples.md).

## Review

- unit test boundaries
- integration tests
- API tests
- component tests
- E2E tests
- mocks
- stubs
- test fixtures
- flaky tests
- edge cases
- negative scenarios
- concurrency scenarios
- failure scenarios

Avoid testing implementation details unnecessarily.

Do not chase test coverage percentage simply for the metric.

Prefer tests that validate important behavior.

## Output

1. Risk — what must not break (authz, money, persistence, the user-visible path).
2. Recommended pyramid for this change — which level, why, and what not to duplicate.
3. Findings (Critical / Important / Improvement) on existing tests: flake, over-mocking, missing negatives, testing private internals.
4. Concrete tests to add — names, inputs, expected behavior. Include at least one failure/negative case when behavior has an error path.

A test that only asserts a mock was called with a private shape is usually an Improvement to delete, not a gap to fill.

## Examples

**Choose a level**
User: What should we test for idempotent order creation?
Do: Integration/API test against the real uniqueness/idempotency path. One E2E happy path max. Do not add a unit test that only asserts `repo.save` was called.

**Coverage chase**
User: We are at 78%, get us to 90%.
Do: Refuse tests that only lift the badge. Name the untested important branches instead. See [examples.md](examples.md).