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 In the old days, this might have been called "writing a spec". But such things aren't done anymore. 🙃

@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.

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!