Follow
My (untested) idea: documentation-driven programming.
1) Document what your program should do, either in a docstring or user-facing doc.
2) Write tests that match that documentation.
3) Write code that is exercised by the tests.
The point is the documentation always comes first and is the final authority as to what is a "defect."
@dl I did that for Markless and some other stuff. It's time intensive.
@dl this seems kinda indistinguishable from TDD to me. A TDD approach's tests should read pretty similarly to documentation.
@dl In the old days, this might have been called "writing a spec". But such things aren't done anymore. 🙃