# Testing QA

> Practical testing rules for unit, integration, and end-to-end verification.

- Skill: `abivan-tech/testing-qa` (Agent Skill)
- Install (CLI): `npx skillmds@latest add abivan-tech/testing-qa`
- Raw SKILL.md: https://api.skillmd.com/api/skills/abivan-tech/testing-qa/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- License: See repository LICENSE
- Author: ABIvan-Tech (https://skillmd.com/u/abivan-tech)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/abivan-tech/testing-qa

---


# Testing & QA Practices

Use this skill when adding tests, fixing failing tests, or deciding how to verify a change safely.

## Priorities

1. **Test real behavior**
2. **Keep tests deterministic**
3. **Match test scope to risk**
4. **Prefer fast feedback**
5. **Keep tests maintainable**

## Core Rules

### 1. Start with the smallest useful test

- Unit tests for isolated logic
- Integration tests for contracts between components
- E2E only for critical user journeys and system-level confidence

Do not jump to the heaviest test layer first unless the bug or requirement is only visible there.

### 2. Test behavior, not implementation trivia

- Assert observable outcomes.
- Avoid coupling tests to internal helper structure unless that structure is the contract.
- Refactors should not break good tests when behavior is unchanged.

### 3. Keep tests deterministic

- Control time, randomness, network, and external services.
- Use fixtures/factories intentionally.
- Avoid sleeps and timing races when a proper wait/trigger exists.

### 4. Cover the exact risk you introduced

For every meaningful change, ask:

- what can regress?
- what edge case is easiest to miss?
- what user-visible behavior proves the fix or feature works?

### 5. Keep verification layered

- narrow automated checks first
- broader integration next when needed
- manual verification for UX, environment-specific flows, or things automation cannot cheaply prove

## By Test Type

### Unit

- ideal for pure logic, mapping, formatting, validators, reducers, helpers
- should be fast and isolated

### Integration

- use for DB interactions, API contracts, module boundaries, queue/worker behavior, or framework integration
- prefer realistic wiring with limited mocking

### End-to-End

- reserve for high-value journeys
- keep scenarios independent
- avoid bloated end-to-end suites that duplicate lower-level coverage

## Good Testing Defaults

- add a regression test for bug fixes when the repo has tests
- prefer factories over giant inline fixtures
- keep one test focused on one behavior
- name tests so failure explains the broken expectation

## Review Heuristics

Look for:

- tests that assert implementation details instead of behavior
- missing regression coverage for the changed risk
- non-deterministic waits and sleeps
- over-mocking that hides real integration bugs
- giant fixtures that make failures hard to reason about
- E2E coverage used where a smaller test would be clearer

## Anti-Patterns

Avoid:

- asserting every internal call in routine code
- snapshot-heavy testing without meaningful review discipline
- tests that only prove mocks were configured
- one huge test covering many unrelated behaviors
- fragile selectors in UI tests when stable hooks exist

## Quick Checklist

- [ ] Test scope matches the risk
- [ ] Behavior under test is explicit
- [ ] Test is deterministic
- [ ] Regression path is covered when relevant
- [ ] Mocks are limited to true external boundaries
- [ ] Manual verification steps are noted when automation is insufficient