Training in 2027: judging tests is the bottleneck

A coding agent writes more tests in seconds than you would write in a day. They are green, and code coverage goes up. Whether they test what your software is supposed to do, or merely record what it does right now, including its bugs, is something the agent does not tell you. Writing tests is therefore no longer the bottleneck. What is scarce is the judgement whether a test is any good, and the ability to tell an agent what it is supposed to test and what it is supposed to implement.

I have built my training programme for 2027 around this bottleneck. In most of its thirteen courses a coding agent plays a part: as the author of tests that you assess, as the recipient of rules that you set, or as the reader of test output that is not supposed to fill its context window. You will find all courses at a glance on the training page.

The public dates are held in German unless a card below says otherwise. Every course is also available in English for your team alone.

The foundation comes before the first test

Judging a test requires that you know what a good test looks like. Where is that knowledge supposed to come from when an agent writes most of the tests? This question runs through the whole programme.

My answer begins with “Understanding Testing”. This course lays the theoretical foundation on which you then learn and practise writing tests, and on which you assess tests, no matter who wrote them. In its six sessions you do not write code, you read it. You learn the concepts and principles of testing, from the oracle of a test through F.I.R.S.T. and test doubles to the question of what code coverage measures and what it does not, and apply them to tests put in front of you, many of which an agent wrote.

The order is deliberate: first the foundation, then writing and assessing. If your project cannot wait that long, you attend “Getting Started with PHPUnit” in parallel. There you set up what your project needs for tests to become part of everyday work, from the organisation of the test suite through the test run in a container and in CI to a test database with synthetic data. You do not write tests yourself in this course; they come from the practice project or from your agent.

When agents write tests, somebody has to decide what those tests look like. In the first session of “Tests by Design” you decide which tests a project needs and which rules they follow, and you justify every decision. In the second you make the rules checkable with a strict configuration of PHPUnit and with PHPStan, so that a tool reports every deviation, including those of an agent.

The agent writes, you are responsible

In “Agentic PHPUnit” you work with your own coding agent. It writes the tests, you assess them, against the requirement rather than against the code. An agent that reads your code writes down what the code does, and if the code has a bug, the tests confirm it. You learn to instruct the agent with an AGENTS.md and the right prompts, to give it guardrails that stop weak tests before you have to read them, and to tell tests that merely record current behaviour from tests of the requirement that survive the next refactoring. Because agents do not answer deterministically, every exercise produces different test suites, and comparing several of them teaches you more than one would.

“Test-Driven Development with AI Agents” reverses the direction. Here you write the tests yourself, and you write them first: they specify what the agent implements. That requires you to master test-driven development. You therefore learn it from the ground up in the first four sessions, without AI, in ensemble programming at a shared screen. Only in the last two sessions do you transfer the way of working to your agent, and a quality gate of coding standard, PHPStan, Deptrac, PHPUnit and Infection decides whether its implementation is good enough.

Green does not mean correct

Even a test suite that you have assessed carefully only tests the examples somebody thought of. “Testing Beyond Examples” shows you three techniques that find what nobody thought of. You learn property-based testing with the new support in PHPUnit 14. Mutation testing answers the question whether your tests would notice a real bug at all, for every test, including a generated one. Fuzzing feeds your code with input that nobody expects.

What a test suite misses can also be a vulnerability. In “Closing Vulnerabilities for Good” you find vulnerabilities through capture the flag, pin each of them down as a PHPUnit test and then close it. A coding agent helps you to find and fix them. The test decides whether the hole is really closed, and because it stays in the test suite, you notice when the hole opens up again.

Test runs, Git and dependencies have to reckon with agents

An agent does more than write code and tests. It reads the output of your test runs, works in your repository and adds packages to your project. Three courses take this into account.

In “Saving Time and Tokens with PHPUnit” the agent is the reader of your test output. A slow test suite costs time, sprawling test output costs tokens. In the first four sessions you measure where your test suite spends its time and speed it up. In the last two you set up test runs so that an agent reads their result correctly and names a gap in code coverage instead of optimising a number.

“Git Under Control” covers clean commits, what really happens during a merge, and a development model that suits your team. The fifth session shows how several people and agents work at the same time with worktrees without getting in each other's way.

“Dependency Management & Supply Chain Security” starts with what really happens during composer require, install and update, and with the question of which code runs during every installation. The last session asks what a coding agent may change about your dependencies.

Upgrades belong in the calendar

A new PHP version comes out in November, a new major version of PHPUnit in February. Both can be planned for, and three courses follow this rhythm. “What is new in PHP?” puts the new PHP version into context: what it brings, why it was designed the way it was, and what breaks during the upgrade. In “PHPUnit 14 Unwrapped” I spend two hours unwrapping what is new in PHPUnit 14 and why it changed. In “PHPUnit Upgrades Without Surprises” you then bring your test suite from PHPUnit 13 to PHPUnit 14 and make sure that the next upgrade stays small.

Six sessions in three days

Until 2026, each day of a course had one session. From 2027 on there are two, from 10:00 to 12:00 and from 15:00 to 17:00 (Europe/Berlin), on consecutive working days. A course with six sessions therefore takes three days, one with four sessions two days, and one with two sessions a single day. There is no session on a Friday afternoon. The new format goes back to feedback from participants and to the experience that my partner at thePHP.cc, Stefan Priebsch, has gathered with it.

Between two sessions there are now three hours or a night. That is not enough for assignments on your own project, and no course expects any. Where your own code is needed, the courses bring it into the sessions: “Agentic PHPUnit” and “Testing Beyond Examples” each devote their last session to it.

Four courses come with my book

In 2027 my book “PHPUnit Best Practices” comes out, together with an extension for PHPStan and with agent skills. The book gives the reasons for its rules, the extension reports where test code departs from them, and the agent skills hand them to a coding agent in a form it can act on. The idea behind it is the same as behind “Tests by Design”: a rule that a tool checks holds better than one that somebody has to remember in a review.

Participants of “Tests by Design”, “Agentic PHPUnit”, “Test-Driven Development with AI Agents” or “Saving Time and Tokens with PHPUnit” receive the book, the extension and the agent skills.

Where you start depends on your project

The learning paths connect the courses into routes, for example from the first test to working with an agent that writes tests, or to shared testing rules for a team. All dates are listed in the calendar. The courses are booked through thePHP.cc Academy, and the page of every course links to the registration as soon as it is open.

If not a single automated test runs in your project yet, the route begins with “Where Are Your Tests?”, a free hour.

Every one of these courses is also available for your team alone, online or on site, in English or in German. Then we work on your questions and, where it fits, on your code. You can request such a course from thePHP.cc.