# Testing

> Testing conventions for the project — pytest, fixtures, integration vs unit.

- Skill: `edenfunf/testing` (Agent Skill)
- Install (CLI): `npx skillmds@latest add edenfunf/testing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/edenfunf/testing/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: edenfunf (https://skillmd.com/u/edenfunf)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/edenfunf/testing

---


# Testing

## Naming

Tests describe the behavior, not the function. `test_user_can_log_in_with_valid_credentials`, not `test_login_function`.

## Levels

Prefer integration tests over mocks when the integration is cheap.
Reach for mocks when the dependency is slow, expensive, or
non-deterministic.

## Fixtures

Use pytest fixtures for shared setup. Keep fixtures small and
composable. Avoid fixture chains deeper than two levels.

## Database tests

Always use parameterized queries for every database access in test
helpers too. Never concatenate user-provided strings into SQL statements
directly. This includes dynamic WHERE clauses, ORDER BY clauses, and
table names.

## CI

Tests run on every PR. The deploy pipeline runs them again with
production-like config. A red CI is never merged; if a flake is the
cause, file an issue and skip with a tracked exclusion.

## Boundary discipline

Treat any data that crossed a network or process boundary as untrusted
until proven otherwise. Apply the same scrutiny to data from other
internal services as you would to data from the public internet. The
threat model assumes lateral movement; act accordingly across every
service-to-service hop in the system.