Linting, Stan, phpCS, Audit
Karlsruhe, 14.11.2025 (PresseBox) - Als Entwickler sollte man sich immer darauf verlassen können, dass der Code, den man schreibt, so funktioniert wie er soll, und dass er keine Nebenwirkungen auf ältere, bereits bestehende Funktionen hat. Zu diesem Zweck gibt es automatische Tests. Wie mein Team bei der punkt.de diese verwendet, kann man in der Artikelserie über Tests nachlesen.
First things first - Automatisierung
Unsere Tests werden nach jedem Commit und nächtlich (auf dem Main-Branch) von GitLab CI ausgeführt.
Ein sauberer, standardisierter Code ist leichter wartbar
Die erste Stufe für uns ist, dass alle Entwickler des Teams den Code auf die selbe Weise schreiben. Hierfür nutzen wir je nach Programmiersprache diverse Tools:
- phpcs (php)
- yamllint (YAML)
- eslint (TypeScript und JavaScript)
- stylelint (CSS und SCSS)
Zukünftige Fehler verstecken sich in Details
Der nächste Schritt ist phpStan. Dieses Tool prüft, ob der Code so geschrieben ist, dass Datentypen eingehalten bleiben und konsistent sind. Beispielsweise reicht es nicht, ein Array als Array zu definieren - Stan zwingt uns dazu, dass wir definieren, dass es beispielsweise ein Array aus Zahlen ist, welches Strings als Keys besitzt. Stan lässt sich dabei in 9 (zukünftig 10) Levels konfigurieren, jeder Level ist strikter als der Level zuvor. In unserem größten Projekt im Team verwenden wir derzeit Level 8 - Level 9 würde uns dazu zwingen, dass wir mit mixed als Datentyp genauer umgehen, was in einem Umfeld wie TYPO3 mit stellenweise ziemlich flexiblen Collections und Arrays größeren Definitionsaufwand bedeuten würde.
Durch die Prüfungen wird erreicht, dass selbst durch mehrere Schichten Programmiercode und auch durch Fremdcode Datentypen sauber sind, und Funktionen nicht inkorrekt verwendet werden können, was bei neuen Entwicklungen zu besserer Konsistenz verhilft.
Die Ausführung von Stan dauert verglichen mit den Linting-Tests vergleichsweise lang, weswegen wir uns entschieden haben, diese nur im Rahmen der Pipelines auszuführen und nicht direkt innerhalb des git-Workflows.
Sicherheitslücken so früh wie möglich sehen
Im Team haben wir die Entscheidung getroffen, dass wir so weit wie möglich keine Fremdlibraries und -pakete mit bekannten Sicherheitslücken auf Kundenserver zu deployen. Zu diesem Zweck führen wir die Befehle npm audit --omit=dev und composer audit aus, welche die über den entsprechenden Paketmanager installierten Pakete gegen zentrale CVE-Datenbanken prüfen, und betroffene installierte Versionen anmerken. Bei npm ignorieren wir die Dev-Pakete, da diese bei Deployments ausgenommen sind und damit ohnehin nicht auf Kundenservern ausgeführt werden.
Dieser Schritt war uns wichtig genug, dass wir ihn im Rahmen des git-Workflows bei jedem Push ausführen, und wie bei den Linting-Schritten kann ein Entwickler bewusst den Test überspringen - dies ist zum Beispiel dann im Ablauf notwendig, dass man nicht mehrfach Paketupdates in mehreren Branches durchführen möchte. Wir können die betroffenen Versionen in Branches pushen, im main-Branch das Update durchführen und anschließend die anderen Branches rebasen.
Uns ist auch bewusst, dass Sicherheitslücken auch bekannt werden können, wenn wir gerade nicht pushen müssen oder viele Pipelines durchgeführt werden. Daher haben wir weitere Abläufe, um bestehenden Code und Releases zu untersuchen, was aber ein Thema für einen weiteren Blogbeitrag ist.
Ausblick
Dies war der erste von 3 Artikeln zu unseren Tests. Freut euch auf Teil 2 über unseren Umgang mit Unittests und anderen Tests mit phpUnit, und auf Teil 3 für API- und Browsertesting.
Agiles Testing und Prozess-Know-how für Ihr Team:
Egal ob Agentur, Industrieunternehmen oder ein eigenständiges Entwicklerteam: Wenn Sie agile Testing-Prozesse etablieren oder weiterentwickeln wollen, unterstützen wir Sie mit unserem Know-how – sei es durch praxisorientierte Workshops oder durch direkte, projektbezogene Mitarbeit. Wir begleiten Sie von der Einführung agiler Testmethoden über die Optimierung bestehender Abläufe bis hin zur Entwicklung und Umsetzung individueller Testing-Strategien. Sprechen Sie uns gerne an, um gemeinsam Ihre Qualitätssicherung und Entwicklungsprozesse auf ein neues Level zu heben!
