Linting, Stan, phpCS, Audit
(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)
Jedes dieser Tools funktioniert auf die gleiche Art - es prüft den geschriebenen Code auf die Form, die in einer entsprechenden Configdatei vermerkt ist, und stellt sicher, dass kein Entwickler davon abweicht. Wie strikt oder offen die Dateien sind, kann natürlich je nach Team unterschiedlich sein - abgesehen von phpcs, dieses nutzt den per PSR definierten Codestyle von php selbst und kann sogar je nach Version andere Varianten prüfen. Das Besondere bei diesen Tests ist, dass sie bereits im git-Workflow vor einem Commit ausgeführt werden, und damit kein Entwickler unbewusst Code mit inkorrektem Codestyle in das zentrale Repository übertragen kann - wenn es um Work in Progress geht, kann man den Schritt temporär überspringen, was dann aber ein sehr bewusst durchgeführter Schritt ist.
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 genauerumgehen, 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!
Datum: 14.11.2025 - 10:40 Uhr
Sprache: Deutsch
News-ID 2212079
Anzahl Zeichen: 0
Kontakt-Informationen:
Ansprechpartner: Fabian Stein
Stadt:
Karlsruhe
Telefon: +49 (721) 9109-124
Kategorie:
Softwareindustrie
Dieser Fachartikel wurde bisher 12 mal aufgerufen.
Der Fachartikel mit dem Titel:
"Linting, Stan, phpCS, Audit"
steht unter der journalistisch-redaktionellen Verantwortung von
punkt.de GmbH (Nachricht senden)
Beachten Sie bitte die weiteren Informationen zum Haftungsauschluß (gemäß TMG - TeleMedianGesetz) und dem Datenschutz (gemäß der DSGVO).