Research code is usually written to be run once, by its author, on one dataset — and then it is run for three years, by four people, on six datasets. The gap between how it was written and how it ends up being used is where silent errors live. A retracted finding traced to a spreadsheet indexing mistake is not a story about carelessness; it is a story about code that nothing checked.
Testing analysis code is not the same as testing software. You are rarely verifying a function against a specification. More often you are pinning behaviour: this pipeline, on this small fixture, produced these numbers yesterday, and if it produces different ones today something changed and you should know before it reaches a manuscript. That style — regression tests against known outputs — catches most of what actually goes wrong.
The highest-value targets are narrow: coordinate and index conventions, unit conversions, anything reading a file format with a header, and any function where an off-by-one is plausible and silent. You do not need coverage of a plotting script. You need a test on the function that decides which subjects are excluded.
Related¶
Coding environments — a test is only meaningful if the environment is pinned
Containers — the strongest form of the same guarantee
Programming obscurities — the class of bug tests are for