Automattic / Automattic/jetpack-crm

tests/php/readme.md only documents the monorepo workflow, so the suite looks unrunnable from a standalone clone

Open Beginner friendly
#26 1 comment 0 reactions 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.