When product updates are frequent and user expectations are high, maintaining accurate and up-to-date documentation isn’t just a necessity—it’s a competitive advantage.
Docs as Tests is a strategy that keeps your docs in sync with your product. It’s a way to test your docs, just like engineers test their code. It’s a way to make sure that your docs are always accurate, complete, and relevant.
- Validate that your guides, tutorials, API references, and other docs work as written.
- Catch issues in your docs and product—before your users do.
- Reduce the time and effort required to maintain your docs.
- Build user trust by ensuring a consistent user experience between your docs and product.
- Make docs a first-class citizen in your engineering and product development processes.
By testing your doc content against your product UIs and APIs, directly navigating your websites and hitting your API endpoints, you can ensure that your docs are always accurate, complete, and relevant.
With the right tools, Docs as Tests can elevate your docs to a dynamic, living part of your product. Interested? You’re in the right place.
Recent posts
Add Docs as Tests to Your CI/CD Pipeline with GitHub Actions
Adding Doc Detective into a CI/CD pipeline to run tests whenever changes occur in a repository is easy and gives you a flexible and powerful tech doc toolchain. In this guide, we’ll walk through setting up a basic Docs as Code pipeline using the venerable Jekyll static site generator, set up some simple doc detective tests, and put together scripts for a CI/CD pipeline using Github Actions to demonstrate how to automatically test your docs off of each update.
Validate a UI with Cypress
Docs as Tests is a strategy for using docs to test a product, validating both that the docs are accurate and that the product is functioning as expected. That’s a great aspiration, but what does it look like in practice?
Docs as Tests: From Development to Production
The Docs as Tests methodology stems from a simple but profound principle: documentation shouldn’t just inform—it should also verify. By treating each piece of documentation as a test case that gets executed against the product, teams can preemptively identify discrepancies and ensure that what users read is what they get.
Validate Commands and Scripts with Doc Detective
We’ve covered how to validate UI procedures and API procedures with Doc Detective, but what about shell commands and scripts? After all, not every procedure is navigating through UIs or making API calls.
Docs as Tests vs. Docs as Code
Documentation has the critical role of helping users keep their footing in the storm of continuous releases driven by the iterative nature of modern product development. While many people think of documentation as creating guides and references for new features, publishing them online, and moving on to the next feature, this simply doesn’t reflect the actual challenges of technical writing in the age of continuous deployment, agile development, continuous contact, and easy access to feedback from customers. Writing is a big part of docs, of course, but maintaining those docs slides into the background as the business, product, and audience shift around them.
Validate an API with Doc Detective
Docs as Tests draws on many of the same principles as test-driven-development and data-driven-development and, as such, is a natural fit for REST API documentation.
Validate a UI with Doc Detective
Docs as Tests is a strategy for using docs to test a product, validating both that the docs are accurate and that the product is functioning as expected. That’s a great aspiration, but what does it look like in practice?
Docs as Tests: A strategy for resilient docs
It’s a common problem: A user is reading the docs for a product, and they come across a step that doesn’t work. Maybe the UI has changed, or the API has been updated, or the instructions are just plain wrong. Whatever the reason, they’re stuck. They can’t move forward, and they can’t get help because the docs are out of date.