Run any Skill in Manus with one click

frontend-test-strategy

Stars0

Forks0

UpdatedMay 20, 2026 at 20:18

Define focused frontend tests for Next.js user-visible behavior. Use for rendering, interaction, loading and error states, regression coverage, and choosing narrow verification scope.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

kwkraus

kwkraus/edgefront-builder

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

SKILL.md

readonly

name	frontend-test-strategy
description	Define focused frontend tests for Next.js user-visible behavior. Use for rendering, interaction, loading and error states, regression coverage, and choosing narrow verification scope.
argument-hint	Describe the UI behavior change, affected route or component, risky user-visible states, and the desired confidence level.

Frontend Test Strategy

When to Use

Any user-visible frontend behavior change in src/frontend
Missing tests for route/component behavior
Need fast confidence before broader test/build runs

Quick Checklist

Identify highest-risk user-visible behavior changes.
Add tests for happy path and main failure/degraded paths.
Assert rendered output and interaction outcomes.
Run narrow validation before widening scope.

Deep Workflow

Classify change risk: rendering-only, interaction logic, data-fetching behavior, or mixed.
Add/adjust tests for highest-risk paths first:
- Primary success behavior
- Loading/error/empty states where applicable
- Regression path for prior bug behavior
Assert user-observable outcomes (content, controls, navigation), not implementation internals.
Keep tests feature-local and aligned with route/component responsibilities.
Run minimal verification commands for touched frontend scope, then expand only if needed.
Report coverage gaps and follow-up tests when time-constrained.

Decision Points

If behavior change affects accessibility or semantics, include explicit a11y-relevant assertions.
If API contract assumptions changed, coordinate with integration-contract-alignment.
If tests are brittle due to structure coupling, refocus assertions on user-visible behavior.

Completion Checks

New behavior is covered by focused tests.
Assertions validate outcomes users can observe.
Verification scope is minimal but sufficient for touched frontend paths.

More from this repository

same repository

api-contract-design

kwkraus/edgefront-builder

Design ASP.NET Core minimal API request and response contracts. Use for DTO shapes, route and verb decisions, OpenAPI metadata, and compatibility planning before implementation.

2026-05-200

api-test-strategy

kwkraus/edgefront-builder

Define focused tests for ASP.NET Core minimal APIs. Use for endpoint branch coverage, contract assertions, regression planning, and choosing the narrowest useful verification command.

2026-05-200

data-schema-migration

kwkraus/edgefront-builder

Design EF Core schema changes, constraints, and migrations for the backend data model. Use for entity updates, indexes, uniqueness rules, cascade behavior, and migration planning.

2026-05-200

delegated-data-sync-pipeline

kwkraus/edgefront-builder

Design and implement the delegated Graph sync pipeline from fetch through normalization, upsert, and metrics recompute. Use for user-initiated registrations or attendance sync, idempotency, and atomic recomputation.

2026-05-200

deployment-safety-and-rollback

kwkraus/edgefront-builder

Define deployment safeguards, environment protections, and rollback readiness for CI/CD releases. Use when adding or reviewing release jobs, promotion controls, or recovery plans.

2026-05-200

domain-metrics-computation

kwkraus/edgefront-builder

Apply email and domain normalization plus session and series metric rules, including W1/W2 warm-account logic and internal-domain exclusion. Use for domain logic changes, recompute behavior, and mandatory unit-test coverage.

2026-05-200

name	frontend-test-strategy
description	Define focused frontend tests for Next.js user-visible behavior. Use for rendering, interaction, loading and error states, regression coverage, and choosing narrow verification scope.
argument-hint	Describe the UI behavior change, affected route or component, risky user-visible states, and the desired confidence level.

Frontend Test Strategy

When to Use

Any user-visible frontend behavior change in src/frontend
Missing tests for route/component behavior
Need fast confidence before broader test/build runs

Quick Checklist

Identify highest-risk user-visible behavior changes.
Add tests for happy path and main failure/degraded paths.
Assert rendered output and interaction outcomes.
Run narrow validation before widening scope.

Deep Workflow

Classify change risk: rendering-only, interaction logic, data-fetching behavior, or mixed.
Add/adjust tests for highest-risk paths first:
- Primary success behavior
- Loading/error/empty states where applicable
- Regression path for prior bug behavior
Assert user-observable outcomes (content, controls, navigation), not implementation internals.
Keep tests feature-local and aligned with route/component responsibilities.
Run minimal verification commands for touched frontend scope, then expand only if needed.
Report coverage gaps and follow-up tests when time-constrained.

Decision Points

If behavior change affects accessibility or semantics, include explicit a11y-relevant assertions.
If API contract assumptions changed, coordinate with integration-contract-alignment.
If tests are brittle due to structure coupling, refocus assertions on user-visible behavior.

Completion Checks

New behavior is covered by focused tests.
Assertions validate outcomes users can observe.
Verification scope is minimal but sufficient for touched frontend paths.