# Writing Tests

Kiro Crew repo only: how to write a backend pytest test with NO side effects that does...

- Repository: https://github.com/kirodotdev/KiroCrew (4711 stars)
- Category: Testing
- License: Apache-2.0
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add kirodotdev/KiroCrew --skill writing-tests -g -a claude-code -y`
Codex: `npx skills add kirodotdev/KiroCrew --skill writing-tests -g -a codex -y`
Cursor: `npx skills add kirodotdev/KiroCrew --skill writing-tests -g -a cursor -y`
Gemini CLI: `npx skills add kirodotdev/KiroCrew --skill writing-tests -g -a gemini-cli -y`

## Description

Kiro Crew repo only: how to write a backend pytest test with NO side effects that does not flake. Use when adding, editing, reviewing or debugging a test there: which conftest applies, what leaks (temp dirs, data home, ~/.kiro, cron, threads), the seven flake classes, cross-platform traps.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Writing a Kiro Crew test that does not leak and does not flake

> **Scope guard: this skill applies ONLY to the Kiro Crew source repository** (or a
> worktree of it). Its rules are conventions of this repo's suite. In any other
> project, ignore it.
>
> The canonical, longer reference is
> [`docs/system-specs/common/testing-conventions.md`](../../../../../docs/system-specs/common/testing-conventions.md).
> If this skill and that document disagree, the document wins. What this skill adds is
> the decision order, what to check first, and what the failure looks like when you
> get it wrong.

## Where this skill stops, and which sibling takes over

This skill owns **authoring** a test: isolation, determinism, cross-platform
behaviour, diagnosing a residue failure, and suite speed. Three siblings own the
neighbouring steps, and none of them restates what is here:

| You are doing | Skill |
|---|---|
| Writing, fixing, or speeding up a test | **this skill** |
| Running the build gate in a worktree, and deciding whether a red is yours | **kirocrew-worktree-dev** |
| Driving a branch to a review-ready PR and through CI | **kirocrew-prepare-pr** |
| Polling that PR until it is green | **babysit** |

The line that matters most in practice: **kirocrew-worktree-dev** tells you whether a
failure is yours (re-run it on `origin/main`, mine CI for what is genuinely flaky);
once it is yours, the fix is here. Do not fix a flake from a summary of the
determinism classes, pick the class from the symptom, in Rule 2.

## The two properties, and why they are one problem

A test must be **hermetic** (no effect that outlives it, anywhere but its own tmp dir)
and **deterministic** (same verdict every run, on every platform, in any order). They
are the same problem because the suite runs `-n auto --dist loadgroup`: a side effect
is not just untidy, it is *the input to another test on the same worker*, and it
surfaces as a flake in a file you never touched.

The rest: https://github.com/kirodotdev/KiroCrew/blob/HEAD/src/kiro_crew/builtin_skills/kirocrew-dev/writing-tests/SKILL.md