La parole est aux speakers : Sebastian Bergmann
Jusqu’au Forum PHP 2026, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !
Les conférences
Speed is a byproduct of trustAI-assisted development tools promise unprecedented speed. But without proper foundations, velocity becomes recklessness: technical debt accumulates faster, architectural boundaries erode quicker, and defects ship sooner. The opposite failure mode is just as real: teams that insist on control without speed cannot meet modern market demands. This session distills the essential lessons of a full-day workshop into 40 minutes: how to establish automated safety nets that let teams move faster precisely because they can trust their quality controls. Using PHP and industry-standard tooling as the running example, we trace how traditional quality practices such as automated testing, static analysis, and architectural boundary enforcement evolve in AI-assisted workflows, culminating in a test-driven pattern where humans write specifications as tests and AI agents generate implementations. You will leave with clear criteria for evaluating your own quality infrastructure and a prioritized list of practices to adopt first. The central insight: the practices that make AI collaboration safe are the same practices that make human development fast. That convergence is the path to sustainable speed. |
Past, Present, Future: The PHPUnit StoryI have learnt more from the failures of PHPUnit than its successes. Over the last 25 years, I have witnessed the evolution of testing philosophy from a marginal practice to the bedrock of modern software development. But has the PHP community learned the right lessons? In this presentation, I will share what I have learned from PHPUnit, how my approach has evolved (sometimes unexpectedly), and my thoughts on the future of software development in the age of AI. |
After 26 years of maintaining PHPUnit, do you have any plan for the future of the project if you decide to leave it?
Thank you for this good and important question. It is one our community talks about far too rarely.
I do think about it, of course, but I have no concrete plan. Mostly because I cannot currently imagine stopping. Just as I cannot imagine stopping work altogether for as long as my health allows it. PHPUnit is not a chore I am waiting to hand off. It is still something I enjoy doing.
What I have taken care of is the other scenario, the one where the decision is not mine to make. If something happens to me, someone I trust will be in a position to put the project on a new footing safely. That person is my designated successor for my GitHub account and my Packagist account. That may sound bureaucratic, but those two accounts are the actual keys to the project. Without them, nobody can publish a release, no matter how many people have write access to the source code.
I would encourage every maintainer of a widely used package to think this through. We spend a lot of energy on supply chain security in terms of signatures and dependencies, and very little on the question of what happens when a single person disappears from the equation. In many projects, the honest answer is: nothing good.
You shifted to a faster release cadence for major PHPUnit versions starting with version 10. Does that make your work as the lead maintainer any easier?
Allow me to adjust the premise slightly, because the story is older than PHPUnit 10. I started the annual, early-February major release cadence with PHPUnit 6 on February 3, 2017, and every major version since has shipped in the first week of February. The one break was the gap between PHPUnit 9 in February 2020 and PHPUnit 10 in February 2023: three years, caused by the pandemic and the delay it brought to the development of the new event system that PHPUnit 10 is built on. After that, the yearly rhythm resumed and has held for 11, 12, and 13.
And yes, it makes my work easier. Not because I write less code, but because one major version per year gives me a predictable, recurring opportunity to clean up and to actually remove what I deprecated in the previous cycle instead of carrying it along indefinitely.
That matters more than it may sound. A successful framework must not only add new features, it must also have the courage to remove functionality when it has become redundant, when it causes confusion, or when a better alternative exists. Every feature that stays has a cost: in documentation, in support, in the understanding users have to build, and in maintenance burden. I wrote about a concrete example of that road from an anti-pattern to something clearer here: https://phpunit.expert/articles/from-anti-pattern-to-clarity.html
The fixed date helps everyone else, too. Users know when a new major version arrives and when their current one reaches end of life. Nobody is caught by surprise. Predictability is a feature.
Beyond PHP as a language, building a testing framework demands theoretical expertise in this domain. Where did your interest in testing originate?
Testing was simply how things were done. In the PHP world of that time, it was not done at all. PHPUnit grew out of a discussion with a professor who doubted a tool like JUnit could be implemented for PHP. I had a proof-of-concept after a couple of days, but it took me about a year before I dared to publish the result on cvs.php.net, in November 2001, as part of PEAR.
As for the theoretical expertise: I had the enormous advantage of not having to invent anything. The xUnit architecture already existed: it began with Kent Beck's SUnit for Smalltalk and became widely known through JUnit. I did not need to come up with a theory of testing. I needed to understand an existing one well enough to translate it into a language that, at the time, barely had the object model to support it. The deeper understanding came with the years: from reading, from watching other ecosystems, and above all from seeing what real projects did with the tool. Twenty-six years of bug reports are an education in themselves.
My path before PHP mattered as well, I think. I taught myself to program on an Amiga 500: first BASIC, then C, then Assembly, because I wanted to build demoscene productions. Later I wrote extensions for BBS software in ARexx. None of that was testing, but all of it taught me that software is something you keep working on: you extend it, other people read it, and it has to survive change. Once you believe that, automated testing stops being an academic idea. It is simply how you keep working on something without breaking it.
When I started with PHP, testing was not part of the culture at all. Today it is, and most of the time it happens with PHPUnit. That is the part I am proudest of. Not the framework itself, but the fact that the question is no longer whether you test.
Des conférences présentées par
 Sebastian BERGMANN |
Sebastian Bergmann is the creator and maintainer of PHPUnit, the industry-standard testing framework that has greatly enhanced the professionalism of PHP software development. As a founding partner and consultant at thePHP.cc, he helps teams adopt PHPUnit, optimise its use, and refine their development workflows to produce more testable code. |