Anwendungen testen #

Diese Seite richtet sich an Anwendungsentwickler, die Code ohne Angst ändern möchten. Die eigenen Tests und Qualitätsschranken des Kernels sind das Vorbild: Die meisten Tests laufen ohne Datenbank, einige gegen eine Wegwerf-Datenbank, und Prüfungen von Templates, Links und im Browser vervollständigen das Bild (Standard für Tests und CI).

Inhalt #

1. Die Ebenen
2. Unit-Tests ohne Datenbank
3. Tests mit Datenbank
4. Prüfungen von Templates, Einstellungen und Links
5. Browserprüfungen
6. Vor jedem Push

Die Ebenen #

Unit-Tests ohne Datenbank #

Schreiben Sie die Logik als einfache Klassen (Dienste), die Ansicht, Befehl und Cronjob aufrufen; testen Sie diese mit PHPUnit (PHPUnit-Tests ohne Datenbank). Der Kernel führt seine gesamte Standard-Suite ohne Datenbank aus: vendor/bin/phpunit schließt die Gruppe database aus.

Tests mit Datenbank #

tests/runtests.php --dsn <dsn> --db-per-test führt die Suiten gegen eine Wegwerf-Datenbank aus, wie es der Datenbank-Job der CI tut. Kennzeichnen Sie solche Tests mit @group database. Richten Sie Tests niemals auf eine Datenbank, die echte Inhalte enthält.

Prüfungen von Templates, Einstellungen und Links #

php bin/php/eztemplatecheck.php -s<siteaccess> extension/expdemo/design/   # every template of your extension
./console exp:ini where expdemo.ini/ListSettings/DefaultLimit <siteaccess>  # settings resolve as expected
./console exp:help check                                                    # links in your extension's docs, when indexed

Browserprüfungen #

• Verwenden Sie einen eigenen Testbenutzer, der für den Lauf angelegt und danach entfernt wird; niemals ein gemeinsam genutztes Administratorkonto, dessen Einstellungen jemandem gehören.
• Prüfen Sie jeden Seitentyp Ihrer Erweiterung abgemeldet, als eingeschränkter Benutzer und als Redakteur.
• Prüfen Sie die Browserkonsole auf Fehler und das CSP-Berichtslog (var/log/csp.log) auf blockierten Code (Content Security Policy für Anwendungen).
• Lassen Sie auf jeder Seite einen Barrierefreiheitsprüfer laufen (Barrierefreiheit testen).

Vor jedem Push #

• To do: php -l für geänderte PHP-Dateien; Template-Prüfung für geänderte Templates.
• To do: Die Unit-Tests des geänderten Codes bestehen.
• To do: Keine Inline-Skripte oder -Styles hinzugefügt.
• To do: Autoloads neu generiert, falls sich Klassen geändert haben; Caches geleert; die Funktion von Hand ausprobiert.
• To do: CI für das Repository eingerichtet (CI für Erweiterungen).

Verwandte Seiten #

• PHPUnit-Tests ohne Datenbank
• Qualitätsprüfungen
• Qualitätsschranken und Abnahme
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.