Mit PHPUnit 13 hat Maintainer Sebastian Bergmann eine neue Major-Version des verbreiteten Test-Frameworks für PHP vorgelegt. Das Release bringt funktionale Neuerungen, entfernt länger veraltete APIs und zieht die technischen Anforderungen an. Ziel ist es laut dem Projekt, Tests klarer zu formulieren und Missverständnisse zu reduzieren.

Aktuelle PHP-Version erforderlich

PHPUnit 13 setzt PHP 8.4 oder neuer voraus und schließt ältere PHP-Versionen aus. Zur Begründung verweist PHPUnit auf den aktuellen Stand der PHP-Entwicklung: Derzeit entwickeln die PHP-Verantwortlichen nur noch PHP 8.4 und 8.5 aktiv weiter.

Gleichzeitig rät PHPUnit zu einem überlegten Upgrade. Der Wechsel auf eine neue Major-Version soll bewusst erfolgen. Wer mit PHPUnit 12.5 noch Deprecation-Warnungen erhält, sollte diese zuerst beheben, bevor ein Umstieg auf Version 13 erfolgt.

Neue Assertions für Arrays

PHPUnit 13 ergänzt das bestehende Angebot um neue Assertions für Arrays. Sie richten sich an Anwendungsfälle, in denen die bisherigen Methoden assertSame() und assertEquals() nicht fein genug zwischen Vergleichsanforderungen unterscheiden.

Die neuen Assertions erlauben es, Array-Vergleiche genauer zu spezifizieren. Dabei lässt sich festlegen, ob Werte strikt inklusive Typen oder lediglich inhaltlich verglichen werden, ob Array-Schlüssel berücksichtigt werden sollen und ob die Reihenfolge der Elemente relevant ist.

Damit stellt PHPUnit zusätzliche Werkzeuge bereit, um bestimmte Vergleichsszenarien expliziter auszudrücken, etwa bei Vergleichen unabhängig von Sortierung oder bei strikt identischen assoziativen Arrays.

Änderungen bei Mock-Objekten

Bei Mock-Objekten ändert PHPUnit 13 die Prüfung von Übergabeparametern und verabschiedet sich von der Methode withConsecutive(), die bislang dazu diente, unterschiedliche Parameter für aufeinanderfolgende Methodenaufrufe zu prüfen. An ihre Stelle treten zwei spezielle Regeln, mit denen sich Parameterfolgen über mehrere Aufrufe hinweg überprüfen lassen.

Der bisherige Ansatz stieß auf bekannte Grenzen, etwa durch die enge Bindung an eine feste Aufrufreihenfolge und eine zunehmende Unübersichtlichkeit bei komplexeren Szenarien. Gerade seit PHPUnit 10 waren daher häufig zusätzliche Konstruktionen nötig, um entsprechende Aufrufsequenzen abzubilden. Ziel der Neuerung ist es, Erwartungen an Mock-Objekte klarer zu formulieren und die zugehörigen Prüfungen übersichtlicher zu halten.

Versiegelte Test-Doubles als neue Option

Neu hinzugekommen sind sogenannte sealed test doubles. Mit ihnen schließt PHPUnit die Konfiguration von Mock- oder Stub-Objekten bewusst ab. Ein Stub dient dabei als einfacher Platzhalter für eine Abhängigkeit und liefert festgelegte Rückgabewerte, ohne Aufrufe zu überprüfen. Nach dem Aufruf von seal() lassen sich weder weitere Erwartungen noch zusätzliche Methoden definieren. Bei Mock-Objekten sorgt das zudem dafür, dass nicht ausdrücklich erwartete Methodenaufrufe zurückgewiesen werden.

PHPUnit führt diese Funktion als optionale Ergänzung ein. Bestehende Tests bleiben unverändert lauffähig, lassen sich aber gezielt strenger einstellen, wenn unerwartete Interaktionen frühzeitig auffallen sollen.

any()-Matcher kurz vor dem endgültigen Rausschmiss

Der Matcher any() ist in PHPUnit 13 als „hart veraltet“ (hard-deprecated) markiert. Gemäß Ankündigungsbeitrag liegt das daran, dass Mock-Objekte primär zur Überprüfung konkreter Interaktionen gedacht sind. Wer keine Aufrufe verifizieren möchte, soll stattdessen Stubs verwenden.

Support-Zeiträume und Ausblick

PHPUnit 13 wird gemäß Übersichtsplan der Versionen bis Februar 2028 mit Bugfixes versorgt. PHPUnit 12 bleibt noch bis Februar 2027 im Support, ältere Versionen erhalten keine Fehlerkorrekturen mehr.

Für 2026 sind mehrere Minor Releases der 13er-Reihe geplant. PHPUnit 14 ist derzeit für Februar 2027 angekündigt. Nähere Informationen zu PHPUnit 13 finden sich im Ankündigungsbeitrag sowie im Changelog.

(mdo)

Die Frage „Wie motiviere ich meine Mitarbeiter?“ wurde mir unzählige Male von Vorgesetzten gestellt. Überraschenderweise ist mir die Frage „Wie motiviere ich meinen Boss?“ nie begegnet. Da der Begriff nicht einheitlich verwendet wird, sei kurz erwähnt, dass ich unter Boss jede Person mit Führungsverantwortung für einen Bereich verstehe.

Sind Vorgesetzte immer motiviert?

Wenn man bedenkt, dass ein Vorgesetzter A selbst Mitarbeiter seines Vorgesetzten B ist, müsste das angebliche Motivationsproblem ja auch für Person A gelten. Also dürfte es aus der Perspektive von B auch bei A mal an Motivation fehlen.

Aber auch aus Sicht eines Teams von Person A zweifle ich den Zustand von „permanenter Motivation“ an. Denn von Teams höre ich nicht selten, dass es ihnen an Führung fehlt. Teammitglieder erkennen sehr wohl Defizite bei Vorgesetzten, nur bringen sie das nie mit Motivation in Verbindung.

Geht es hier eigentlich um Motivation oder um etwas anderes?

Ein Beispiel: Ein Entwickler, mit dem ich gearbeitet habe, hat seinen Bereichsleiter um ein Mitarbeitergespräch gebeten. Es hatte schon lange keines mehr stattgefunden und so hatten sich beim Mitarbeiter einige Themen aufgestaut. Acht Monate, nachdem der Mitarbeiter erstmals um das Gespräch gebeten hatte, hatte es immer noch nicht stattgefunden. Augenscheinlich war der Manager nicht sonderlich motiviert, das Gespräch zu führen. Als ich das Thema bei ihm ansprach, gab er offen zu, dass er sich lieber um technische Fragen kümmere. Es machte den Eindruck, dass alles, was an seiner Position mit Personalführung zu tun hatte, nicht „sein Ding“ war.

Nun kann man eine solche Situation (mit einigem Recht) grundsätzlich beklagen, das hilft aber nicht weiter und beantwortet die wichtigste Frage nicht: Was soll der Mitarbeiter in dem Fall tun?

Im Allgemeinen rate ich dazu, herauszubekommen, was den Vorgesetzten interessiert; anders gesagt, was ihn motiviert. Möchte er bei seinem eigenen Vorgesetzten gut dastehen? Möchte er sich um bestimmte Themen möglichst wenig kümmern? Möchte er, dass die Aufgaben, die man erledigt, möglichst geräuschlos und im Zeitplan erledigt werden? Und so weiter.

Im zweiten Schritt geht es darum, das eigene Anliegen mit der vermuteten Motivation des Vorgesetzten in Verbindung zu bringen.

Unterschiedliche Strategien

Im obigen Beispiel des Vorgesetzten, der „seine Ruhe“ haben möchte, gibt es verschiedene Strategien – von entgegenkommend bis konfrontativ. Entgegenkommend wäre es zum Beispiel, die Planung des Gesprächs in die eigene Hand zu nehmen, eine Agenda mit den eigenen Themen aufzustellen und das alles in einen Kalendereintrag zu schreiben. Wenn man im Kalender die freien Slots des Vorgesetzten sehen kann, wählt man einen Termin und lädt ihn ein.

Konfrontativ wäre der Ansatz, seinen Boss in allen anderen stattfindenden Meetings an den Gesprächswunsch zu erinnern. Also auch in Besprechungen, in denen das Thema nichts zu suchen hat. Irgendwann – so die Hoffnung – hat man genug genervt und bekommt einen Termin. Ob diese konfrontative Ansprache eine gute Idee ist, dürfte sehr stark vom persönlichen Verhältnis zum Vorgesetzten abhängen. Und es ist wichtig, den richtigen Ton zu treffen. Keinesfalls sollte man das eigentliche Thema des Meetings behindern. Wenn aber der Vorgesetzte zum Abschluss eher floskelhaft fragt: „Sind wir durch oder habt Ihr noch ein Thema?“ kann eine beiläufige Erwähnung der Art „Wir wollten ja noch unser Mitarbeitergespräch führen. Wann passt es denn?“ funktionieren.

Ein dritter Weg, den ich sehr erfolgreich anwenden konnte, besteht darin, für die Themen, die der Vorgesetzte bearbeiten soll, eigene Tickets im Teamboard (sic!) zu schreiben. Das funktioniert besonders gut, wenn sich die Führungskraft als Teil des Teams sieht. Falls man es irgendwie rechtfertigen kann, dass diese Tickets als Blocker für andere Arbeiten des Teams herhalten können, steht das Team früher oder später still, wenn der Chef nicht liefert.

Bei Teams, die ihre Arbeit mit Metriken beobachten, kann so eine Vorgehensweise die Auswertungen ziemlich verschlechtern. Bleiben die fraglichen Tickets lange unbearbeitet, erhöht sich die Cycle Time. Im obigen Beispiel wäre das Ticket „Mitarbeitergespräch führen“ mindestens 8 Monate alt geworden. Das ist in den Umgebungen, die ich kenne, eine sehr schlechte Cycle Time. Falls das ein KPI ist, der im Unternehmen sichtbar gemacht wird, möchte der Vorgesetzte bestimmt nicht, dass dieser Sachverhalt an die große Glocke gehängt wird. Bei diesem Weg macht man sich also die Motivation zunutze, dass der Vorgesetzte Wert auf sein Ansehen in der Firma legt.

Letztlich läuft es in all diesen Fällen darauf hinaus, im Falle eines (unmotiviert wirkenden) Vorgesetzten, die Führung im jeweiligen Einzelfall selbst zu übernehmen.

Erst lesen, dann hören

Nach dem Schreiben des Artikels ist die Idee entstanden, die Frage „Wie motiviere ich meinen Boss?“ im Gespräch mit Führungskräften zu diskutieren. Die Gespräche finden live und online und – bei entsprechender Nachfrage – regelmäßig statt. Die Anmeldung ist kostenlos.

(rme)

Die neueste Ausgabe der jährlichen Umfrage State of JavaScript präsentiert die Antworten von mehr als 10.000 Entwicklerinnen und Entwicklern weltweit, die ihre beliebtesten sowie am häufigsten genutzten JavaScript-Tools mitteilen. React ist erneut das meistgenutzte Frontend-Framework und Vite wieder das beliebteste Tool insgesamt.

Das meistgenutzte Tool webpack kann dagegen wenig Begeisterung wecken, denn der Bundler gilt als schwerfällig, mühsam und veraltet – und Vite ist ihm in der Nutzungshäufigkeit eng auf den Fersen. Unter den Texteditoren sticht der neuere KI-Editor Cursor besonders hervor, kann es jedoch nicht mit Visual Studio Code aufnehmen.

Vite sägt rasant an webpacks Thron

Die Studie hat erneut nicht nur nach der Nutzung von JavaScript-Libraries gefragt, sondern auch nach den positiven, negativen oder neutralen Einstellungen, die Entwickler ihnen gegenüber hegen. Die Libraries sind in verschiedene Kategorien gruppiert, darunter Frontend- oder Backend-Frameworks sowie Build-Tools. Gesamtsieger in der Nutzungshäufigkeit ist der Bundler webpack, doch das Build-Tool Vite ist ihm auf Rang 2 eng auf den Fersen und hat in diesem Jahr React überholt.

Ein Blick auf die meistgenutzten Build-Tools zeigt, wie eng dieses Mal das Rennen um den ersten Platz war: webpack nutzen 86,4 Prozent der Teilnehmenden im Jahr 2025, während Vite mit 84,4 Prozent knapp dahinter liegt. Die Betrachtung über die letzten Jahre hinweg zeigt, dass sich die Schere zwischen webpack und Vite immer weiter schließt. In der Umfrage 2023 betrug der Unterschied zwischen den Tools noch 17 Prozent, 2024 nur noch acht Prozent.

Auf der Beliebtheitsskala steht Vite ganz oben: Unter denjenigen, die das Tool bereits verwendet haben, stehen ihm 56 Prozent positiv gegenüber, dagegen nur ein Prozent negativ. In den Freitext-Kommentaren zu Vite überschlagen sich die Lobeshymnen. Es sei einfach zu nutzen, die beste Technologie in seinem Bereich oder gar „die einzige Wahl im Jahr 2025“.

webpack als veralteter, schwerfälliger Albtraum

Am unbeliebtesten unter seinen Nutzern ist webpack: 37 Prozent der Befragten, die webpack einsetzen, bewerten es negativ. Lediglich 14 Prozent der webpack-User haben dem Tool gegenüber eine positive Einstellung. Die Freitext-Antworten bemängeln unter anderem, webpack sei „schwerfällig und veraltet“, habe „extrem langsame Kompilierungszeiten“ und die Konfiguration sei ein Albtraum. Andere Kommentare loben Vite oder Turbopack als bessere Alternativen.

KI-Coding mit Cursor

Bei den Texteditoren liegt Microsofts Visual Studio Code in der Nutzung mit 84 Prozent weiterhin mit Abstand vorne. Auf dem zweiten Platz landet Cursor: 26 Prozent der Befragten verwenden die KI-gestützte Entwicklungsumgebung, die somit alteingesessene Entwicklungsumgebungen und Editoren wie JetBrains WebStorm oder Vim (jeweils 20 Prozent) verdrängt.

Nach den KI-Tools gefragt, die sie regelmäßig zum Schreiben von Code verwenden, nennen die Teilnehmenden in erster Linie ChatGPT, GitHub Copilot, Claude, Gemini und Cursor. Claude hat dabei einen deutlichen Sprung in der Nutzung vorzuweisen – mit einem Zuwachs um 22 Prozentpunkte im Vergleich zum Vorjahr.

Diese und weitere Ergebnisse der Studie können Interessierte im Detail auf der Website zum State of JavaScript 2025 betrachten. Auch die früheren Ergebnisse der seit 2016 jährlich durchgeführten Umfrage sind auf der Website des Projekts zu finden.

(mai)