test-at-the-behavioral-boundary

Test at the highest stable boundary—public functions or object contracts—and assert observable properties like outputs, classes, dimensions, and names. Avoid asserting private helper calls or internal structure, so implementation changes do not break the suite.

A regression test reproduces a concrete historical defect: it fails before the fix and passes after. A characterization test captures existing behavior of poorly tested public methods before maintenance, protecting only behavior you intend to preserve.

Test private helpers only when they have a clear semantic contract, multiple callers, or edge behavior that is expensive to reproduce through public APIs. Even then, prefer behavior-based assertions over structural ones.

Use tolerances appropriate to the algorithm, scale, and platform rather than exact floating-point equality. Set seeds for stochastic methods, and separate structural assertions (class, dimensions, names) from numerical ones.

No. Test only the integration boundary: that your adapter selects correct data, aligns observations, forwards key arguments, and returns the expected upstream class. Do not duplicate the dependency's own validation suite.

Avoid snapshots for large numerical objects, volatile metadata, platform-sensitive output, or objects where only a few fields matter. Reserve them for stable textual summaries, print methods, and error reports where full structure matters.