>> How do you write automated tests for documentation? Somehow require that blocks of code have documentation linked to them?
It could be tests to ensure documentation "builds" into all of the desired formats (e.g. web, pdf, ebooks, etc.) correctly.
Some programming languages have the idea of "documentation tests". In Rust, tests that are part of the documentation will run as part of the documentation build:
If we treat specifications written in gherkin syntax [0] as documentation, then the cucumber framework can match a line or stanza of gherkin to a test function [1].
I admit that, while I write instructions for how to test specific functionality in gherkin, our company would not countenance publishing a non-narrative description of the system's behavior to our client's employees.
Short version: have tests that use introspection (listing functions and classes in a module, iterating over JSON API endpoints in the codebase etc) and then run regular expressions against your documentation searching for relevant headings or other pre-determined structures.
In matlab, where functions are "always" defined in their own file, there is a tool that checks if function documentations have all the right headers expected conventionally by matlab's documentation system (e.g. header, usage, examples, see-also links, etc). So this would be one example, I guess.
But I too would be interested to hear other people's insights who subscribe to this Docs as Code model.
It could be tests to ensure documentation "builds" into all of the desired formats (e.g. web, pdf, ebooks, etc.) correctly.
Some programming languages have the idea of "documentation tests". In Rust, tests that are part of the documentation will run as part of the documentation build:
https://doc.rust-lang.org/rustdoc/write-documentation/docume...