Automattic / Automattic/jetpack-crm
tests/php/readme.md only documents the monorepo workflow, so the suite looks unrunnable from a standalone clone
- Dominant language
- PHP
- Stars
- 13
- Forks
- 8
- Avg merge
- 1d 10h
- Merged PRs (30d)
- 13
Description
`tests/php/readme.md` documents running the tests from inside the Jetpack monorepo only:
> 1. Run `jetpack install plugins/crm`
> 2. Go to the crm plugins directory `projects/plugins/crm`
> 3. Run `composer run-script phpunit`
None of that applies to a standalone clone of this repo, which is how it ships and what `make up` sets up. `make test` runs `composer phpunit`, which needs a WordPress test library the readme never mentions, so the first thing you hit is a fatal about a missing `wp-settings.php`.
The test library is already there. `make up` starts wp-env, and its tests container ships the WordPress test suite at `/wordpress-phpunit` with the plugin mounted, so the whole suite runs with one command:
```sh
docker exec -w /var/www/html/wp-content/plugins/jetpack-crm zero-bs-crm-tests-cli-1 \
sh -c 'WORDPRESS_DEVELOP_DIR=/wordpress-phpunit php vendor/bin/phpunit -c phpunit.12.xml.dist'
```
Worth documenting, along with a few things that took a while to work out:
- `composer phpunit` does not work inside the container. It calls `vendor/bin/phpunit-select-config`, which uses `pcntl_exec`, and that isn't available there. Call `vendor/bin/phpunit` directly with the config matching your PHPUnit version.
- `phpunit.12.xml.dist` is a symlink to `phpunit.11.xml.dist`. If you are adding a `` and dutifully edit "both", you write the same file twice and end up with a duplicated block.
- `WP_Ajax_UnitTestCase` puts its tests in the `ajax` group, which the WordPress bootstrap excludes unless you pass `--group ajax`. Tests written on it are silently skipped, so a suite that never runs still reports green.
- `wp_send_json()` only sets a status code when `headers_sent()` is false, which it never is under PHPUnit. Asserting on a handler's response status passes regardless of what the handler decided, so those assertions are worth nothing. Assert on the body instead.
`make lint` has the same gap. `composer cs` shells out to `phpcs-changed`, which isn't in `require-dev` and isn't vendored, and there's no `vendor/bin/phpcs` either, so linting can't be run from a standalone clone at all. Either add the dependency or say plainly in the readme that linting is monorepo-only.
Happy to send a PR if the direction looks right.
Contributor guide
No contributing guide indexed for this repository
Research direction
Update tests/php/readme.md, starting by comparing its monorepo instructions with the standalone workflow described in the issue and the make up test container. Document the direct PHPUnit command, configuration and test-group caveats, and clarify the standalone make lint limitation or dependency status. Done means a standalone clone can find the test command and understand whether linting is supported.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, php
- Domain
- documentation, testing-qa
- Issue type
- Documentation
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 76/100