What would you actually write tests for in a machine learning pipeline?

Test the deterministic parts properly and the stochastic parts behaviorally. Unit test feature transforms against fixtures, enforce schema and range contracts on inputs, keep a golden row test that loads the serialized pipeline and checks known inputs produce known scores, and write behavioral tests on model outputs (invariance, directional expectations) rather than asserting an exact accuracy number.

Most of a pipeline is ordinary code and tests exactly like ordinary code. Feature transforms get unit tests against small fixtures, including the ugly cases: nulls, a category never seen in training, a negative value where only positives were expected. Input data gets contract checks, so schema, types, ranges, and expected null rates, run as a gate before training rather than discovered afterward as a weird model. Then a golden row test, where I keep a serialized pipeline and a handful of fixed inputs with their expected scores, and CI fails if a refactor changes them. That has caught silent preprocessing changes for me more than once. For the model itself I do not assert accuracy above some number, because that is flaky and a bad gate. I write behavioral tests instead: invariance, so changing an irrelevant field barely moves the score, and directional expectations, so increasing a feature we know is monotonically related moves the prediction the right way. Full training runs are too slow for every commit, so those go nightly, with a fast smoke training on a tiny sample in CI to prove the pipeline still runs end to end.