This document explains how to maintain and update the documentation in this project.
This project uses an automated documentation generation system that extracts PHPDoc comments from source code and converts them into Markdown files for the docs directory. This ensures documentation stays synchronized with the codebase.
Documentation is written in PHPDoc comments directly in the PHP source files. The system follows this pattern:
Location: Source files in src/ directory (traits, classes, etc.)
Format: PHPDoc comments with Markdown-style formatting
Example (see src/test/Queues.php or src/test/BrowserHelpers.php):
/**
* # Feature Name
*
* Overview paragraph explaining what this feature does and why it's useful.
*
* ## Installation (if applicable)
*
* ```bash
* composer require package-name --dev
* ```
*
* ## Basic Usage
*
* Explanation with code examples:
*
* ```php
* it('does something', function() {
* $result = $this->doSomething();
* $result->assertSuccess();
* });
* ```
*
* ## Additional Sections
*
* More examples and explanations...
*/
trait FeatureName
{
/**
* Method-level documentation.
*
* Describes what the method does with examples:
*
* ```php
* $this->methodName('param');
* ```
*/
public function methodName(string $param)
{
// implementation
}
}Location: src/bin/generate-docs.php
Purpose: Parses PHP files and extracts documentation from PHPDoc comments
How it works:
- Takes two arguments: source PHP file path and output Markdown file path
- Uses reflection to read class and method documentation
- Strips PHPDoc comment markers (
/**,*,*/,@param, etc.) - Preserves Markdown formatting (headers, code blocks, lists, etc.)
- Outputs clean Markdown files
Usage:
php src/bin/generate-docs.php src/test/BrowserHelpers.php docs/browser-testing.mdLocation: .github/workflows/docs.yml
Purpose: Automatically generates documentation on pull requests
How it works:
- Triggers on pull requests
- Sets up PHP 8.3 environment
- Installs Composer dependencies
- Runs
generate-docs.phpfor each documented feature - Commits and pushes the generated Markdown files back to the branch
Current documented features:
- Factories
- Entry/Asset factories
- DOM node lists and forms
- HTTP response assertions
- Element assertions
- Database assertions
- Request builders
- Console response assertions
- Benchmarking
- Cookies
- Authentication (logging in)
- Queue testing
- Snapshots
- Browser testing (newly added)
- CLI commands
When you need to document a new feature, follow these steps:
- Open the relevant PHP source file (trait, class, behavior, etc.)
- Add comprehensive PHPDoc comments at the class level
- Use Markdown formatting for structure:
# Main Titlefor the feature name## Section Headersfor different topics```phpand```for code blocks```bashand```for shell commands
- Document public methods with their own PHPDoc comments
- Include practical examples in all documentation
Key principles:
- Write from the user's perspective
- Include installation steps if needed
- Show common use cases
- Provide copy-paste ready examples
- Explain WHY, not just HOW
- Open
.github/workflows/docs.yml - Find the "Generate docs" step (line ~37)
- Add a new line following the existing pattern:
php src/bin/generate-docs.php src/path/to/YourFile.php docs/your-feature.md - Place it logically with related documentation (e.g., testing features together)
Before committing, test that documentation generates correctly:
php src/bin/generate-docs.php src/path/to/YourFile.php docs/your-feature.mdThen review the generated Markdown file:
cat docs/your-feature.mdCommit both the source file with documentation AND the workflow update:
git add src/path/to/YourFile.php
git add .github/workflows/docs.yml
git commit -m "Add documentation for new feature"The generated Markdown file (docs/your-feature.md) will be created automatically by the GitHub Actions workflow when you create a pull request.
Start with a main heading and comprehensive overview:
/**
* # Feature Name
*
* 1-2 paragraphs explaining what this feature does, why it exists,
* and when to use it.
*
* ## Installation
*
* Include if the feature requires additional packages.
*
* ## Basic Usage
*
* Always include a simple, working example first.
*
* ## Common Patterns
*
* Show typical use cases.
*
* ## Advanced Usage
*
* Optional: Complex scenarios or power-user features.
*/Focus on practical usage:
/**
* Brief description of what the method does.
*
* Optional longer explanation of behavior or important notes.
*
* ```php
* // Example usage
* $this->methodName('example');
* ```
*
* @param string $param Description
* @return mixed Description
*/- Use complete, runnable examples
- Include context (test wrappers, setup, etc.)
- Add comments to explain non-obvious parts
- Show realistic scenarios, not toy examples
- Use
##for section headers (h2) - Use
```phpfor PHP code blocks - Use
```bashfor shell commands - Use inline `code` for function names, variables, file paths
- Keep lines readable (wrap around 80-100 characters when possible)
Update documentation when:
- Adding new public methods
- Changing method signatures
- Modifying behavior
- Adding new features
- Discovering common use cases that should be documented
Don't document:
- Private/protected methods (unless truly necessary)
- Internal implementation details
- Methods marked with
@internal - Magic methods like
__construct,__call, etc. (usually) - Deprecated features (remove their documentation)
After the GitHub Action runs:
- Check that the Markdown file was created/updated
- Verify formatting looks correct (headers, code blocks, lists)
- Ensure code examples are readable
- Confirm no PHPDoc tags leaked through (like
@param,@return)
Problem: generate-docs.php throws an error
Solution:
- Ensure the source file path is correct
- Verify the PHP file has no syntax errors
- Check that the output directory exists
Problem: Code blocks or headers don't render correctly
Solution:
- Ensure proper spacing around code blocks (blank line before/after)
- Check that code fence markers are
```not` - Verify asterisks for lists have space after them
Problem: Public method docs aren't in the generated Markdown
Causes:
- Method might be inherited (only declaring class methods are included)
- Method might not be public
- Method might start with
__(magic methods excluded) - Method might have
@internaltag
Problem: Docs not updating on PR
Solution:
- Check that
.github/workflows/docs.ymlis committed - Verify the workflow has proper permissions
- Check GitHub Actions tab for error messages
- Ensure the branch is not protected against bot commits
This was recently added as an example of the full process:
-
Updated source file:
src/test/BrowserHelpers.php- Added comprehensive class-level PHPDoc with installation, usage, examples
- Included sections for basic usage, assertions, debugging, device testing
- Showed both Craft-specific (
visitTemplate) and standard Pest features
-
Updated workflow:
.github/workflows/docs.yml- Added line:
php src/bin/generate-docs.php src/test/BrowserHelpers.php docs/browser-testing.md - Placed after queue.md and before cli.md
- Added line:
-
Tested locally:
php src/bin/generate-docs.php src/test/BrowserHelpers.php docs/browser-testing.md
-
Result:
docs/browser-testing.mdcreated with full documentation
Follow this same pattern for future documentation additions.