Whilst the core message of your comment I agree with, unit tests are not the only way to achieve this; but there's often blanket statements made about 100% code

Whilst the core message of your comment I agree with, unit tests are not the only way to achieve this; but there's often blanket statements made about 100% code coverage, and all that nonsense - which really just fetishizes unit testing rather than critically thinking about the goal of a unit-test. For example, better use of types to make sure applications physically can't get into a bad state will always have better returns in terms of velocity and correctness than checking after the fact with unit-tests. It has the additional benefit of being compositional, unlike unit tests. This can be done for data representation but also transitions of state, which is all of software engineering outside of IO.