Unit Tests for Physics Code

Small automated tests pin the behaviour of each function, so a change that breaks the physics is caught the moment it is introduced.

Testing the smallest pieces

Physics code is code, and it earns the same discipline as any critical software. A unit test exercises a single function against a known answer -- a limit, an analytic case, a conservation identity -- and fails loudly if the function stops returning it. Thousands of these run automatically on every change.

What good physics unit tests check

• Known limits: does the function recover the analytic answer in a case with a closed form?
• Symmetry and invariance: does it respect symmetries the physics demands?
• Conservation: does it conserve what it should on a small controlled problem?
• Boundary behaviour: does it handle edges, zeros, and extremes without silently returning nonsense?
• Units: does the returned quantity carry the expected dimensions?

Why this is a standard, not a nicety

Integrated results like Q_sci 3.424 or fusion power 88.7 MW are built from many functions. If any one drifts unnoticed, the headline number is silently wrong and looks fine. Unit tests convert a silent drift into an immediate, located failure, which is the difference between catching a bug in an afternoon and shipping it in a paper.

Tests are also documentation: a well-written test states, in executable form, what a function is supposed to do. When a reviewer asks what a routine guarantees, the tests are the honest answer. The habit costs a little time on every change and repays it many times over, because the alternative is trusting that a large body of coupled physics code stayed correct on faith, which is not a standard at all.