This is something I _really_ like about D.
Unit-tests are built into the language, as is comment-based documentation—put those two together and you get unit-tests as documentation examples built into the language; all it takes is to put a documentation comment (which can be blank) right before a `unittest` block after a declaration.
I took the same "docs are tests and tests are docs" approach with integration testing when I created this library: https://github.com/hitchdev/hitchstory
I realized at some point that a test and a how-to guide can and probably should actually be the same thing - not just for doctests (https://docs.python.org/3/library/doctest.html), but for every kind of test.
It's not only 2x quicker to combine writing a test with writing docs, the test part and the docs part reinforce the quality of each other:
* Tests are more easily understandable when you attach written context - the kind that is used when generating a readable how-to guide.
* How to docs are better if they come attached to a guarantee that they're tested, not out of date and not missing crucial details.
* Integration test driven development where how-to docs are created as a side effect is really nice.
E.g. the examples for the D standard-library's `curry` function are just unit-tests: the docs: <https://dlang.org/phobos/std_functional.html#quickindex.curr...>; the code: <https://github.com/dlang/phobos/blob/42b8c65ccfd35c863f7cedf...>