Test Research Code

Brings a research code artifact to the state an artifact-evaluation committee (ACM AE, USENIX/OSDI/SOSP, SIGMOD ARI, ETAPS, NeurIPS code release) expects: it runs, it is deterministic enough to reproduce within tolerance, its environment is captured, and a stranger can follow the README to the paper's main result. This is the code-side counterpart to preflight-check for the PDF.

It is not generic software TDD. The goal is one reliable end-to-end "does it run and roughly reproduce" path, not exhaustive unit coverage. A focused smoke test that exercises the real pipeline on a tiny input is worth more than 100 mocked unit tests.

When to use

• The code is "works on my machine" and needs to become runnable by a stranger — no pinned env, no seeds, no obvious entrypoint, no sanity test.
• The author asks to add a smoke/sanity test, pin seeds / make it deterministic, or capture/pin the environment before they package or hand it off.
• An artifact-evaluation deadline is approaching and the code is not yet in testable shape — do this engineering first, then route to the siblings below.

Boundary (avoid overlap). This skill is the engineering step — tests, seeds, env capture. It does not own:

• Packaging, badge taxonomy, archival DOI, anonymization → prepare-artifacts.
• Whether the produced numbers actually match the paper's tables → verify-results.
• General code cleanup/refactor → refactor-research-code. When the request is "get my code ready for the artifact track," start here for the run-ability gaps, then hand off; don't re-do their work.

Inputs