Life after the bridge

For years, symfony/phpunit-bridge was the price of admission for taking deprecations seriously in a Symfony project: a second error handler, an environment variable with its own grammar, @group legacy, and output that only looked right when you ran your tests through simple-phpunit.

Since PHPUnit 10, that has changed, largely because Symfony developers asked for it. #[IgnoreDeprecations] came out of a hallway conversation at SymfonyLive Berlin. The distinction between self, direct, and indirect deprecations. Recognising trigger_deprecation() as a deprecation trigger so the report points at your code instead of the contracts package. Collecting deprecations triggered while autoloading classes, before the first test even runs. Stopping at one specific deprecation message. Chaining a booted kernel's error handler instead of silently giving up. Every one of these landed in PHPUnit because someone in this community opened an issue.

This talk traces that history from PHPUnit 10 to PHPUnit 14, and then gets concrete: what a Symfony project's phpunit.xml looks like when deprecation handling is native, how to migrate an existing test suite, which parts of the bridge still have a job, and where the remaining rough edges are.

This presentation currently exists only as an idea and has not yet been accepted by a conference.

About me

I am the creator and maintainer of PHPUnit, the de facto standard testing framework within the PHP ecosystem. Used by millions of developers, it is embedded in the build pipelines of start-ups, Fortune 500 companies, and public sector organisations alike. I serve on the board of the PHP Foundation and am a co-founder of thePHP.cc, where I advise organisations on testing strategy, software architecture, and keeping large test suites current with the frameworks they depend on.

I have over 25 years of experience working with Open Source software, having contributed to the PHP language itself as well as the tools on which that ecosystem depends. The deprecation handling this talk is about was not designed in isolation. It grew out of issues, pull requests and hallway conversations with Symfony developers who had lived with the bridge for years and knew precisely what it cost them. Deciding which of those requests belong in a testing framework that millions of projects depend on, and which are better solved in a framework's own tooling, is the part of maintaining PHPUnit I want to talk about here.

Upcoming events

More events

Stay up to date with PHPUnit

You can follow @phpunit@phpc.social to stay up to date with PHPUnit's development.

You can subscribe to the PHPUnit Updates newsletter to receive updates about and tips for PHPUnit.

Back to overview