Tests as Documentation
Tests are more valuable when they serve as documentation, and define the implementation of specification.
Tests ought to exist to document the desired usage and behavior of a given system.
This allows you to ship confidently.
If you're unsure of the desired behavior of a system check for a test.
If a test doesn't exist, write the test. Observe the behavior. Then ask if this matches what you'd expect or desire the behavior to be.
If it matches, awesome. You're done. Commit the test to answer the question for your future self and other future engineers.
If it doesn't match, then determine how it needs to change.
With this in mind, it's easy to use the desired behaviors to guide the implementation and code review. It then serves as documentation, and defines the specification for when the work is done.
Finally, it allows actual refactoring, changing the implementation without changing the behavior.
None of this is new. It's all behavior driven development (BDD).