Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I said documentation generated from literate tests (this does not exist yet), not tests as the final documentation artifact. The result would be similar to API docs, but derived from a more authoritative resource (tests, not docblocks).

> I don't want to read through a dozen different edge conditions

Neither do I. You mean you want the happy path in a distinct scenario. That is a very common perception amongst both testers and documentation writers. Good test suites have the happy path distinct from the edge conditions as well as good docs.



I don't think it is possible to usefully deliver what you want, but if you can do that I'm all for it. Just having the code in my documentation checked that it compiles (which often means assumptions because I shouldn't have to put in boilerplate)


Python doctests[1] scratch that idea, but in another angle. They are useful and popular.

clitest[2] is more closely related to what I'm aiming for, and it's very useful, but hard to translate to non-shell paradigms.

I am sure it can be done.

[1]: https://docs.python.org/3/library/doctest.html

[2]: https://github.com/aureliojargas/clitest




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: