Testing the docs
Doc Detective uses itself to test its own documentation. Learn how to write tests for documentation and when they’re required.
When to add tests
Required for substantial contributions
Tests are required when documenting:
- New features with user-facing actions
- Step-by-step procedures
- Configuration changes
- UI workflows
- Command-line operations
Optional for standard contributions
Tests are optional but recommended for:
- Adding examples to existing docs
- Troubleshooting procedures
- Tutorial content
- How-to guides
Not needed for quick contributions
Tests are not needed for:
- Typo fixes
- Clarifying existing content
- Updating links
- Fixing formatting
- Conceptual explanations
What makes a good documentation test
Good tests verify that documented procedures actually work:
✅ Do test:
- Steps users follow produce expected results
- UI elements exist where documentation says they do
- Code examples execute without errors
- Links resolve to real pages
- Screenshots match current UI
⛔ Don’t test:
- Grammar and style (use Vale for this)
- Spelling (automated spellcheckers handle this)
- Internal implementation details
- Edge cases not mentioned in docs
Test file structure
Tests are defined in .spec.json files, typically placed alongside the documentation they test.
Basic test structure
Test components
Test metadata
Steps (actions)
Each step is an action Doc Detective performs:
Common actions:
goTo: Navigate to a URLfind: Verify an element existsclick: Click an elementtype: Enter textcheckLink: Verify a link worksscreenshot: Capture a screenshot
See Actions for all available actions.
Example: Testing a tutorial
Let’s say you documented this tutorial:
Tutorial: Create your first test
- Create a file named
test.spec.json - Add a test that navigates to doc-detective.com
- Run the test with
npx doc-detective
Corresponding test
This test:
- Creates the test file as documented
- Runs it as documented
- Cleans up after itself
Running tests locally
Prerequisites
- Local development environment set up
- Doc Detective installed (included in
package.json)
Run all tests
This runs all .spec.json files in the repository.
Run specific tests
Run tests for a directory
View test results
Test results are output to testResults-<timestamp>.json in the repository root:
Common test patterns
Verify page content
Test that documented content exists:
Test command-line examples
Verify command examples work:
Test navigation flows
Verify user can navigate as documented:
Verify links
Test that documented links work:
Capture screenshots
Take screenshots for documentation:
Test configuration
Test contexts
Define test contexts for different environments:
Environment variables
Use environment variables for dynamic values:
Set in .env file:
Debugging failing tests
Common failure causes
Element not found
Error: find action can’t locate selector
Solutions:
- Check selector syntax (CSS or XPath)
- Wait for page to load fully
- Verify element exists on page
- Check for typos in selector
Example fix:
Timing issues
Error: Actions happen before page is ready
Solutions:
- Add
waitactions between steps - Use
findto wait for elements - Increase timeout values
Example fix:
Environment differences
Error: Tests pass locally but fail in CI
Solutions:
- Check for hardcoded paths
- Use environment variables
- Verify dependencies are installed
- Check for timing differences
Command failures
Error: Shell commands fail
Solutions:
- Verify command is available in environment
- Check working directory
- Use full paths when needed
- Add error handling
Enable debug logging
Get detailed test output:
Test best practices
Keep tests straightforward
✅ Do:
- Test one concept per test
- Use clear, descriptive IDs
- Keep steps minimal
- Test what users actually do
⛔ Don’t:
- Test implementation details
- Create overly complex scenarios
- Test multiple features in one test
- Rely on external services when possible
Make tests maintainable
✅ Do:
- Use comments to explain complex steps
- Group related tests in the same file
- Use descriptive action parameters
- Clean up after tests (delete files, etc.)
⛔ Don’t:
- Hardcode values that might change
- Create dependencies between tests
- Leave test artifacts behind
- Use brittle selectors
Write defensive tests
Account for common issues:
CI/CD integration
Tests run automatically in GitHub Actions:
When tests run
- On every pull request
- On commits to main branch
- Can be run manually from Actions tab
Viewing CI test results
- Go to your pull request
- Check the “Tests” status check
- Click “Details” to see full output
- Failed tests show specific error messages
Failing CI tests
If tests fail in CI but pass locally:
- Check the logs: Click “Details” on the failed check
- Look for environment differences: Paths, dependencies, timing
- Run tests in Docker (mimics CI environment):
- Ask for help: Comment on the PR with the error details
When to skip tests
It’s okay to skip tests when:
- Changes are purely conceptual (no procedures to test)
- Testing would require external services unavailable in CI
- The benefit doesn’t justify the maintenance cost
- Quick fixes that don’t change user-facing procedures
In these cases, note in your PR: “Tests not added because [reason]“
Getting help with tests
Resources
- Doc Detective docs: Test documentation
- Actions: All available actions
- Example tests: Browse
.spec.jsonfiles in this repository - Discord: Ask in the #documentation channel
Test review
Maintainers review tests as part of PR review. They can help with:
- Improving test structure
- Fixing failing tests
- Optimizing test performance
- Deciding what to test
Don’t hesitate to ask for help. Testing documentation is a unique skill.
Next steps
- Write your first test: Add a test for your contribution
- Run tests locally: Verify tests pass before submitting PR
- Learn more: Read the full test documentation
- See examples: Browse existing
.spec.jsonfiles for patterns