testing-general

Stars8

Forks3

UpdatedApril 1, 2026 at 23:54

Language-agnostic testing principles: boundary assertions, null checks, and behavior-driven test naming

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.

Source

ucdavis

ucdavis/ai-skills-registry

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

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

SKILL.md

readonly

name	testing-general
description	Language-agnostic testing principles: boundary assertions, null checks, and behavior-driven test naming

Testing — General

Structure

One test file per source module.
Name tests as specifications: "should <behavior> when <condition>".
Group related cases with describe/context blocks.
Follow Arrange-Act-Assert (AAA), with a blank line between each phase.

What to Test

Happy path: expected inputs produce expected outputs.
Edge cases: empty input, zero, maximum values, boundary conditions.
Error paths: invalid input, missing data, external failures.

Mocking

Mock only what you don't control: HTTP calls, databases, filesystems, clocks.
Never mock the unit under test.
Restore mocks after each test to prevent state leakage.

Assertions

Assert specific values, not just that something was called.
On error paths, assert both the error type and message.
Avoid assertions inside loops — use parameterized tests instead.

Coverage

Focus on behavior coverage, not line coverage.
100% coverage does not mean a test suite is complete.
Missing: edge cases, concurrent access, failure paths that coverage tools can't see.

More from this repository

same repository

architecture-general

ucdavis/ai-skills-registry

Architecture decisions: layering, design patterns, microservices trade-offs, and domain-driven design

2026-04-018

architecture-python

ucdavis/ai-skills-registry

Python architecture: PEP-8, type hints, clean layering, dependency injection, and testing strategy

2026-04-018

code-review-general

ucdavis/ai-skills-registry

General code review process: priority ordering, what to block on, how to give actionable feedback

2026-04-018

data-science-python

ucdavis/ai-skills-registry

Python data science: notebook structure, data validation, reproducibility, and model documentation

2026-04-018

git-workflow-general

ucdavis/ai-skills-registry

Git workflow: branch naming, conventional commits, PR conventions, and merge strategies

2026-04-018

refactoring-typescript

ucdavis/ai-skills-registry

TypeScript refactoring: SOLID principles, DRY, type safety improvements, and eliminating code smells

2026-04-018

name	testing-general
description	Language-agnostic testing principles: boundary assertions, null checks, and behavior-driven test naming

Testing — General

Structure

One test file per source module.
Name tests as specifications: "should <behavior> when <condition>".
Group related cases with describe/context blocks.
Follow Arrange-Act-Assert (AAA), with a blank line between each phase.

What to Test

Happy path: expected inputs produce expected outputs.
Edge cases: empty input, zero, maximum values, boundary conditions.
Error paths: invalid input, missing data, external failures.

Mocking

Mock only what you don't control: HTTP calls, databases, filesystems, clocks.
Never mock the unit under test.
Restore mocks after each test to prevent state leakage.

Assertions

Assert specific values, not just that something was called.
On error paths, assert both the error type and message.
Avoid assertions inside loops — use parameterized tests instead.

Coverage

Focus on behavior coverage, not line coverage.
100% coverage does not mean a test suite is complete.
Missing: edge cases, concurrent access, failure paths that coverage tools can't see.