Scaffold tests
The PHPUnit suite in .eddy/tests validates the scaffold itself: the install.php flow, the tooling commands and their installer, and the structure of the project that results.
Running the self-tests
Run these from the repository root. Install the dependencies once:
composer --working-dir=.eddy/tests install
| Action | Command |
|---|---|
| All tests | composer --working-dir=.eddy/tests test |
| A single group | composer --working-dir=.eddy/tests test -- --group=p0 |
| A single class | composer --working-dir=.eddy/tests test -- --filter=InstallTest |
| With coverage | composer --working-dir=.eddy/tests test-coverage -- --group=p0 |
| Coding standards | composer --working-dir=.eddy/tests lint |
| Fix standards | composer --working-dir=.eddy/tests lint-fix |
phpunit.xml stops the run at the first error, failure, warning or risky test, so a run that ends early can still print an "OK, but there were issues!" footer. Compare the test count with the expected total.
Test groups
Tests are tagged p0 to p5 so CI can run them as parallel jobs:
| Group | What it covers | Needs |
|---|---|---|
p0 | The in-process unit suite. | PHP only. |
p1 | InstallTest, the snapshot test of install.php. | PHP only. |
p2 | AssembleTest (the codebase assembly) and ToolingInstallerTest (the tooling installer driving a real Composer). | A Drupal-friendly PHP setup. |
p3 | AhoyTest, plus AutoPortDiscoveryTest and WaitForPortTest, which run real webservers and sockets. | Ahoy and a WebDriver backend. |
p4 | MakeTest. | make and a WebDriver backend. |
p5 | XdebugTest, the XDebug toggle through both wrappers. | Ahoy, make, and xdebug with xdebug.mode=off. |
A WebDriver backend is a Selenium container or a local Chrome driven by chromedriver. p5 is the only group that runs with the real xdebug extension instead of pcov, so it collects no coverage.
Regenerating snapshot fixtures
InstallTest runs install.php end to end and compares the result with the fixtures in .eddy/tests/fixtures/install/: a _baseline directory plus 1 directory per dataset. The fixtures are generated, so never edit them by hand, apart from the .ignorecontent rule files. After any change that affects the output of install.php, regenerate them:
- Commit your source changes first, as their own commit.
- From
.eddy/tests, run the update command:
cd .eddy/tests
composer update-snapshots
It commits a changed baseline on its own and adds the dataset fixtures to that commit, or commits them on their own when the baseline didn't change. Review the result with git show --stat and confirm composer test -- --filter=InstallTest passes before pushing.
.eddy/tooling/ isn't part of a generated project, so a change confined to it needs no regeneration.
Continuous integration
The Test Eddy workflow, .github/workflows/eddy-test.yml, runs the suite across the p0 to p5 groups on Ubuntu and macOS, and runs p3 and p4 once per WebDriver backend: Selenium on Ubuntu only, chromedriver on both. It also builds and tests these docs, and lints the workflows with yamllint and actionlint and checks them for security issues with Zizmor.
install.php deletes every .github/workflows/eddy-*.yml from a generated project, so a maintenance-only workflow takes the eddy- prefix and a workflow that ships to projects never does.