Testing and Continuous Integration

Automated tests catch errors as they are introduced; continuous integration runs those tests on every change, keeping code trustworthy.

Why test

A test is code that checks other code does what it should. Without tests, a change that quietly breaks a calculation may go unnoticed until it has corrupted a decision. Tests turn correctness from a hope into a measured, repeatable property.

Levels of testing

• Unit tests: check a single function against known inputs and outputs.
• Integration tests: check that components work together.
• Regression tests: lock in a known-good result so it cannot silently change.
• Convergence and verification tests: check that solvers meet expected accuracy.

A minimal example

def tritium_margin(tbr):
    return tbr - 1.0

def test_tritium_margin():
    assert tritium_margin(1.8) == 0.8
    assert tritium_margin(1.0) == 0.0

Continuous integration

Continuous integration (CI) runs the full test suite automatically whenever code changes. A change that breaks a test is flagged before it merges, not after it ships. This keeps the shared codebase in a known-good state at all times, which is what makes rapid iteration safe.

Tests as documentation

Well-written tests also document intent: they show, by example, what each function is supposed to do at its boundaries. A new contributor can read the tests to learn how a component behaves, and can trust that behavior because CI enforces it on every commit.