Unsere Tests werden nach jedem Commit und nächtlich (auf dem Main-Branch) von GitLab CI ausgeführt.
Die Teststages eines nächtlichen Laufes:
Das Testergebnis:
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:
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.
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.
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.
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.
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!
