review-testslisted

Review changes to this TMDB API testing framework against its own conventions and gotchas — the project-specific checks that generic code review misses. Use after writing or editing an API client, endpoint method, test module, fixture, Pydantic schema, test-data YAML, or assertion helper, and before committing/opening a PR. Covers schema dual-registration, module-scope test data, the API-client/test separation, response validation via Pydantic + assert_http_response, and the known flaky-endpoint exemption. Complements (does not replace) the built-in /code-review for generic bugs.
pgundlupetvenkatesh/mdb_api_layer · ★ 0 · Testing & QA · score 60

Install: claude install-skill pgundlupetvenkatesh/mdb_api_layer

# Review test changes Review the current diff for violations of *this repo's* conventions. These are the rules generic review can't know — they come from CLAUDE.md and the code. Run the generic `/code-review` separately for correctness bugs; this skill is only the convention/gotcha pass. ## Scope Look at the change under review (`git diff`, `git diff --staged`, or the edits just made). For each file touched, run the checks below that apply. Verify every claim against the actual code — open the file, grep for the symbol — do not assert from memory. ## Checks ### 1. Schema dual-registration (highest-value, easy to miss) A new or renamed Pydantic model must be registered in **both** places: - `tests/schemas/models.py` — the model definition. - the `load_schema` map in `tests/conftest.py` — name → model. A model present in one but not the other is a bug. Grep both files for the schema name and confirm it appears in each. ### 2. Module-scope test data Parametrized test data must be loaded at **module scope**, not inside a fixture or method: `TEST_DATA = load_test_data("test_data.yaml", "<section>")` as a module-level constant. `@pytest.mark.parametrize` runs at collection time, before fixtures exist, so a fixture-loaded value breaks. Confirm the second arg names a real top-level YAML section (a wrong/missing section raises `KeyError`), and that access stays scoped to that section (`TEST_DATA["<section>"][...]`). ### 3. No HTTP logic in tests Tests must not call `requests`,