Menu
Reference for the vivarium pytest setup. Use this skill when running, debugging, or developing automated test coverage.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Guided iteration loop for a vivarium model — take one model change from a research-spec doc through a staged artifact→component→observer build, InteractiveContext verification, review, and a PR. Use when the user asks to implement or iterate a model concept (a cause, risk, intervention, or observer) in an existing model repo from its vivarium-research documentation, or names a MIC ticket that points at one.
Use when the user asks about vivarium-suite CI — build status, Jenkins console logs, job structure, GitHub Actions runs, etc. Covers the GH Actions / Jenkins setup, the per-package Multibranch Pipeline layout, URL-to-jobFullName translation for the Jenkins MCP, and parallel matrix log interleaving.
SimSci Engineering team convention for drafting a Design Document on the IHME hub. Use whenever the user asks to e.g. "draft a design doc", "write a design document", "make a design doc", or "start a PRD".
Reference for the shared `make` targets used across vivarium repositories, centralized in `vivarium/build_utils/resources/makefiles/`. Use this when the task involves making a new conda environment, formatting code, running development checks, or type hinting. Use whenever the user asks what a `make <target>` does in a vivarium repo, mentions running `make` in this ecosystem, or whenever another skill or instruction says "run `make X`" and you need to know exactly what it does, its arguments, env vars, and side effects.
Internal building block invoked by /viv:code-reviewer (and framework-development's review phase): runs the multi-agent review fan-out + functional-correctness pass + per-finding confidence scoring + synthesis on a diff the caller has already gathered. Not a review entry point — to review a PR, use /viv:code-reviewer.
Use after a code review when some findings won't be addressed in the current PR — triages them into Jira ticket recommendations. Classifies each unaddressed finding (address-now / ticket / drop), groups ticket candidates by theme, checks the MIC backlog for duplicates via the `_duplicate_finder` sub-agent, then drafts and files tickets per team conventions, every write gated on explicit user approval. Trigger on "triage the findings", "file tickets for the rest", "turn these review comments into tickets", or when the user defers review findings after `/viv:code-reviewer`.
| name | pytest |
| description | Reference for the vivarium pytest setup. Use this skill when running, debugging, or developing automated test coverage. |
The recommended way to run tests is via make test-* targets, which include coverage reporting and built-in support for several markers. For quick iteration on a single test, running individual pytest commands is acceptable. In general, you should start by testing narrowly within the scope of the current task, and run a more comprehensive make command (e.g. make test-all) before major workflow points like submitting a pull request.
make test-* targets:
make test-all # everything
make test-unit # only tests/unit/
make test-integration # only tests/integration/
make test-e2e # only tests/e2e/
Each target runs pytest -vvv --cov --cov-report term --cov-report html:./output/htmlcov_<type> tests/<type>. To enable @slow and/or @weekly tests, pass them as make variables (NOT pytest flags):
make test-all RUNSLOW=true RUNWEEKLY=true
make test-unit/-integration/-e2e only work in repos that actually have the matching tests/<type>/ subdir — most vivarium repos don't (test layouts are flat or domain-organized). Check ls tests/ first; otherwise fall back to make test-all or direct pytest.
test_<module>.py file that parallels the source module you're changing (e.g. tests for results/observation.py go in tests/.../results/test_observation.py). Don't create a per-feature test file — the team organizes tests by the code under test, not by feature.class Test…: and lift the common setup into a fixture or helper (DRY), but keep each distinct requirement in its own test method — e.g. one test asserts dtype/category order, another asserts numeric columns stay numeric. Shared setup, asserts doled out per test. (This is a common preference, not universal across existing code — match the surrounding file when it clearly does otherwise.)vivarium_testing_utils auto-loads as a pytest plugin and registers markers with default-skip rules. Look at vivarium/testing_utils/pytest_plugin.py (in libs/testing-utils/) to understand their behavior. If a test is mysteriously skipping, you may also run pytest with -v (or -rs) and read the skip reason.
Coverage is automatically outputted by make test-* targets. When writing a new test, be mindful of code coverage, but don't take it as a blocking priority. Use it as a way to understand whether your test is actually testing the code you think it is, and to identify any gaps in your test.