Testing Configuration

This page is a reference for the two configuration files that control how the test suite is discovered, bootstrapped, and executed: phpunit.xml and testbench.yaml. It covers every field in each file and explains why each setting exists.

For information about what the tests actually assert and how they are structured, see 6.2. For how the CI pipeline invokes these configurations, see 6.4. For the development workbench application itself, see 6.1.

---

phpunit.xml

phpunit.xml1-21

This is the root PHPUnit configuration file. It controls test discovery, the bootstrap process, environment injection, and the source root used for code coverage.

Annotated Field Reference

Field / Attribute	Value	Purpose
bootstrap	vendor/autoload.php	Loads the Composer autoloader before any test runs. No custom bootstrap script is needed.
colors	true	Enables ANSI colour output in the terminal.
testsuite name	"Feature"	The single named suite. All tests live under tests/Feature/.
directory	tests/Feature	PHPUnit scans this directory recursively for test files.
APP_ENV	testing	Tells Laravel (via Testbench) to use the testing configuration profile.
APP_KEY	base64:uz4B1Rt…	A fixed application key required by Laravel's encrypter at boot time in the test environment.
source > include > directory	src	Scopes code-coverage reporting to the package's production code only; workbench and test files are excluded.

Structure Diagram

Diagram: phpunit.xml — Structure and Relationships

Sources: phpunit.xml1-21

---

testbench.yaml

testbench.yaml1-34

Orchestra Testbench uses this file to configure the temporary Laravel application that is spun up during tests. It defines which service providers to load, which migrations to run, what the workbench development server exposes, and how assets are built and synchronized.

Top-Level Fields

Field	Value	Description
laravel	'@testbench'	Uses Testbench's own bundled Laravel skeleton rather than a custom one.
providers	(commented out)	No additional providers are explicitly registered here. The package provider is auto-discovered via composer.json.
migrations	workbench/database/migrations	Runs the workbench migration files against the test database on setup.
seeders	Workbench\Database\Seeders\DatabaseSeeder	Seeds the database using the workbench's DatabaseSeeder after migrations.

workbench Block

Controls the embedded development server and asset/route discovery when running composer serve or the Testbench build commands.

Field	Value	Description
start	'/'	Default route when opening the workbench server in a browser.
install	true	Runs workbench:install automatically when starting the server.
health	false	Disables the /health endpoint.

discovers Flags

Controls which parts of the workbench application are auto-discovered and registered:

Key	Value	Effect
web	true	Registers routes in workbench/routes/web.php.
api	true	Registers routes in workbench/routes/api.php.
commands	true	Registers Artisan commands from the workbench app.
components	false	Blade components are not auto-discovered.
factories	true	Model factories in workbench/database/factories/ are registered.
views	false	Views are not auto-discovered.

build Step Sequence

Testbench runs these steps in order when composer build (or composer prepare) is invoked:

Order	Step	Description
1	asset-publish	Publishes vendor assets to the workbench public directory.
2	create-sqlite-db	Creates the SQLite database file used during tests.
3	db-wipe	Drops all tables to ensure a clean slate.
4	migrate-fresh	Runs all migrations from scratch.

assets and sync

Key	Value	Description
assets	laravel-assets	Specifies the asset pipeline step to run.
sync.from	storage	Source directory for file sync (package's storage/ folder).
sync.to	workbench/storage	Destination in the workbench app.
sync.reverse	true	Changes written in the workbench's storage are synced back to the source.

Structure Diagram

Diagram: testbench.yaml — Keys, Values, and Corresponding Workbench Paths

Sources: testbench.yaml1-34

---

Relationship Between the Two Files

Diagram: Test Execution Flow — Config Files to Runtime

Sources: phpunit.xml1-21 testbench.yaml1-34

---

Key Points

• Only one test suite (Feature) is defined. There are no Unit or other suites.
• The APP_KEY in phpunit.xml is a static development key and must never be used in production.
• Coverage collection is limited to src/ phpunit.xml16-20 which means workbench application code and test helpers are excluded from coverage reports.
• The build sequence in testbench.yaml testbench.yaml23-28 is used by composer prepare and composer build scripts (documented in 6.1), not by PHPUnit directly.
• The providers key in testbench.yaml is commented out testbench.yaml3-4 because PhpStormCopilotServiceProvider is registered through Laravel's auto-discovery mechanism declared in composer.json.