PHP PROJEKTEN SOFTWAREQUALITÄT IN. Mit Fallstudien von Firmen wie Facebook und Projekten wie TYPO3, Symfony und Zend Framework

Transkript

1 sebastian BERGMANN stefan PRIEBSCH 2. Auflage SOFTWAREQUALITÄT IN PHP PROJEKTEN Mit Fallstudien von Firmen wie Facebook und Projekten wie TYPO3, Symfony und Zend Framework EXTRA: Mit kostenlosem E-Book

2 Inhalt Geleitwort... XV Vorwort... XVII Teil I Grundlagen Softwarequalität Was ist Softwarequalität? Externe Qualität Interne Qualität Technische Schulden Konstruktive Qualitätssicherung Sauberer Code Explizite und minimale Abhängigkeiten Klare Verantwortlichkeiten Keine Duplikation Kurze Methoden mit wenigen Ausführungszweigen Software-Metriken Zyklomatische Komplexität und NPath-Komplexität Change Risk Anti-Patterns (CRAP) Index Non-Mockable Total Recursive Cyclomatic Complexity Global Mutable State Kohäsion und Kopplung Werkzeuge Fazit Testen von Software Einführung... 17

3 VI Inhalt 2.2 Systemtests Testen im Browser Automatisierte Tests Testisolation Akzeptanztests Grenzen von Systemtests Unit-Tests Rückgabewerte Abhängigkeiten Seiteneffekte Stub- und Mock-Objekte Die Softwaretestpyramide Integrationstests Kollaborierende Systeme ersetzen Datenbanken ersetzen Die GUI (zunächst) ignorieren Frontend-Tests PHPUnit als Infrastruktur Realisierung Fazit Testen von Legacy Code Einführung Praxisbeispiel Vorbereitungen Globale Abhängigkeiten Datenquellen Asynchrone Vorgänge Änderungen in der Datenbank Nicht vorhersagbare Ergebnisse Eingabedaten Weiterführende Überlegungen Fazit Teil II Fortgeschrittene Themen Bad Practices in Unit-Tests Einführung... 83

4 Inhalt VII 4.2 Warum guter Testcode wichtig ist Bad Practices und Test-Smells Duplizierter Testcode Zusicherungsroulette und begierige Tests Fragile Tests Obskure Tests Lügende Tests Langsame Tests Konditionale Logik in Tests Selbstvalidierende Tests Websurfende Tests Mock-Overkill Skip-Epidemie Fazit Kontinuierliche Integration Einführung Kontinuierliche Integration Statische Analyse Installation und Inbetriebnahme Konfiguration Statische Tests Dynamische Tests Reporting Deliverables erzeugen Betrieb Weiterführende Themen Continuous Deployment Einen Reverse Proxy nutzen Kontinuierliche Integration und agile Paradigmen Fazit Testen von Datenbank-Interaktionen Einführung Pro und Kontra Was gegen Datenbanktests spricht Warum wir Datenbanktests schreiben sollten Was wir testen sollten Datenbanktests schreiben

5 VIII Inhalt Die Datenbankverbindung mocken Die Datenbankerweiterung von PHPUnit Die Klasse für Datenbanktestfälle Die Verbindung zur Testdatenbank aufbauen Datenbestände erzeugen Operationen auf den Daten Tests schreiben Den Datenbanktester benutzen Testgetriebene Entwicklung und Datenbanktests Datenbanktests als Regressionstests Probleme mit den Daten testen Probleme testen, die durch Daten sichtbar werden Fazit Gebrauchstauglichkeit Einführung Anything goes aber zu welchem Preis? Designaspekte Barrierefreiheit Lesbarkeit Label für Formularelemente Tastaturbedienbare Webseite Gute Farbkontraste Logo zur Startseite verlinken Alternativtexte für Bilder Hintergrundbild mit Hintergrundfarbe Druckversion nicht vergessen Erkennbare Links Gute Bookmarks Keine Frames Skalierbare Schrift Technische Aspekte Performanz JavaScript Benutzerführung Der Mythos des Falzes Feedback bei Interaktionen Navigation

6 Inhalt IX Popups und andere Störenfriede Gewohnheiten bedienen, Erwartungen nicht enttäuschen Fehlertoleranz und Feedback Testen der Usability Fazit Performanz Einführung Werkzeuge Umgebungsbezogene Gesichtspunkte Lasttests Apache Bench Pylot Weitere Werkzeuge für Lasttests Profiling Callgrind APD Xdebug XHProf OProfile Systemmetriken strace Sysstat Lösungen im Eigenbau Übliche Fallstricke Entwicklungsumgebung gegen Produktivumgebung CPU-Zeit Mikro-Optimierungen PHP als Glue Language Priorisierung von Optimierungen Fazit Sicherheit Was ist eigentlich Sicherheit? Secure by Design Der Betrieb Physikalischer Zugang Software-Entwicklung Was kostet Sicherheit? Die häufigsten Probleme Fazit

7 X Inhalt 10 Testbasierte Entwicklung verkaufen Vom prozeduralen Code zum testbasierten Vorgehen Ziele der testbasierten Entwicklung Aufwände für Software-Entwicklung Möglichst wenige technische Schulden aufnehmen! Offenlegung von Risiken mit ATAM Diskutieren und entscheiden Mit ATAM transparente Entscheidungen herbeiführen Kalkulation testbasierter Entwicklung Risiken als Argumentationshilfe berechnen Langsamere Entwicklung bei höherer Qualität Automatisierungs- und Abdeckungsgrad durch Tests bestimmen Strategische Argumente für die Einführung testbasierter Entwicklung Qualität und Nachhaltigkeit als Teil des Leistungsversprechens Initiale Mehraufwände, die sich für den Auftraggeber lohnen Das Angebot richtig verhandeln Formulierung des Angebots Inhalte des Angebots Ein Angebot ohne Verhandlung abgeben? Fazit Teil III Fallstudien: Open-Source TYPO3: die agile Zukunft eines schwergewichtigen Projekts Einführung Die Geschichte von TYPO3 13 Jahre in 13 Absätzen Den Neuanfang wagen! Unsere Erfahrungen mit dem Testen Grundsätze und Techniken Bittersüße Elefantenstückchen Testgetriebene Entwicklung Tests als Dokumentation Kontinuierliche Integration Sauberer Code Refaktorierung Programmierrichtlinien Domänengetriebenes Design Vorgehen bei der Entwicklung

8 Inhalt XI Neuen Code entwickeln Code erweitern und ändern Code optimieren Fehler finden und beheben Alten Code fachgerecht entsorgen Testrezepte Ungewollt funktionale Unit-Tests Zugriffe auf das Dateisystem Konstruktoren in Interfaces Abstrakte Klassen testen Testen von geschützten Methoden Verwendung von Callbacks Auf in die Zukunft Testen von Symfony und Symfony-Projekten Einführung Ein Framework testen Der Release-Management-Prozess von Symfony Verhältnis von Testcode und getestetem Code Die Ausführung der Testsuite muss schnell sein Gesammelte Erfahrungen Testen von Webanwendungen Die Hemmschwelle für das Testen abbauen Unit-Tests Funktionale Tests Fazit Testen von Grafikausgaben Einführung Entwicklungsphilosophie Die ezcgraph-komponente Architektur Anforderungen an die Tests Ausgabetreiber durch Mock-Objekt ersetzen Mehrfache Erwartungen Structs Generierung der Erwartungen Zusammenfassung Binäre Ausgaben testen

9 XII Inhalt Die Ausgabetreiber Generierung der Erwartungen SVG Bitmap-Erzeugung Flash Fazit Testen von serviceorientierten APIs Die Probleme API-Zugangskennungen API-Beschränkungen Service-Protokolle offline testen Konkrete Services offline testen Fazit Wie man einen WebDAV-Server testet Über die ez WebDAV-Komponente WebDAV Architektur Herausforderungen bei der Entwicklung Anforderungsanalyse TDD nach RFC Den Server testen Automatisierte Akzeptanztests mit PHPUnit Test-Trails aufzeichnen Das Testrezept Integration mit PHPUnit Fazit Teil IV Fallstudien: Unternehmen swoodoo eine wahrhaft agile Geschichte Einführung Evolution: Nur die Starken überleben Wie wir die extreme Seite erreichten Kontinuierliche Integration Testgetriebene Entwicklung Tägliche Standup-Meetings Wo wir schon einmal dabei sind

10 Inhalt XIII User Storys und Story Points Velocity Iterationsplanung Programmieren in Paaren Kollektives Eigentum Offenheit für Änderungen Überstunden Die Kunst der Evolution KISS und YAGNI zwei Seiten einer Medaille Evolutionstheorie und Fazit Qualitätssicherung bei studivz Einführung Akzeptanztests Selenium Die Selenium-Erweiterung von PHPUnit Technisches Setup von studivz Codeumgebung Testumgebung Best Practices Jugendsünden Strategiewechsel Eine DSL muss her Interne DSL Testing_SeleniumDSL Testing_SeleniumDSL 2.0 ein Entwurf Fazit Qualitätssicherung bei Digg Die Ausgangssituation Unsere Probleme Code-Altlasten Wie lösen wir unsere Probleme? Ein Test-Framework wählen Mit einem Experten arbeiten Das Team trainieren Testbaren Code schreiben Statische Methoden vermeiden Dependency Injection

11 XIV Inhalt 18.4 Mock-Objekte Überblick Datenbank Lose gekoppelte Abhängigkeiten Beobachter für klasseninternes Verhalten Memcache Mocken einer serviceorientierten Architektur Der Qualitätssicherungsprozess bei Digg Testen Vorteile Herausforderungen Fazit Schlussbetrachtungen Literatur Stichwortverzeichnis

12 2 Testen von Software Testing is an infinite process of comparing the invisible to the ambiguous in order to avoid the unthinkable happening to the anonymous. James Bach 2.1 Einführung In der klassischen, nicht-iterativen Software-Entwicklung sind Programmierung sowie Integrations- und Systemtests zwei getrennte Phasen im Projekt, die oft von unterschiedlichen Teams durchgeführt werden. Es ist durchaus sinnvoll, wenn die Entwickler nicht ihre eigene Arbeit testen. Ein unabhängiger Tester hat eine ganz andere Sichtweise auf die zu testende Anwendung, da er die Implementierung nicht kennt. Er kann also nur die Bedienoberfläche (oder Schnittstelle) einer Anwendung testen. Dabei bedient er die Anwendung ganz anders als ein Entwickler, der beim Test noch den Code vor Augen hat und daher intuitiv vorwiegend die Funktionalität überprüft, von der er eigentlich weiß, dass sie funktioniert. Ein unabhängiger Tester bewährt haben sich übrigens auch Tests durch Personen, die zum ersten Mal mit der zu testenden Anwendung arbeiten entwickelt im Idealfall ausreichend destruktive Kreativität, um die Arbeit des Entwicklers auf eine harte Probe zu stellen und die Anwendung etwa mit wirklich unsinnigen Eingaben, abgebrochenen Aktionen oder etwa manipulierten URLs herauszufordern. Tests, die ohne Kenntnis der Implementierung durchgeführt werden, nennt man Black- Box-Tests. Tests, die anhand des Quellcodes der zu testenden Anwendung entwickelt werden, nennt man dagegen White-Box-Tests. Auf den ersten Blick scheint das Testen von Webanwendungen besonders einfach zu sein. Das zu testende Programm erhält einen HTTP-Request, also einen String, vom Browser und erzeugt einen HTML-String, der an den Browser zurückgesendet und dort dargestellt wird. Natürlich können auch andere Ausgabeformate wie JSON oder XML erzeugt werden, aber auch diese sind nur Zeichenketten. Ein Test der Webanwendung muss überprüfen, ob das Programm für eine bestimmte Eingabe-Zeichenkette die korrekte erwartete Ausgabe- Zeichenkette erzeugt. Während es in der Tat relativ einfach ist, die Korrektheit der Ausgabe für eine Eingabe zu prüfen, macht es bereits die unüberschaubar große Anzahl von möglichen Eingaben un-

13 18 2 Testen von Software möglich zu überprüfen, ob das Programm für alle möglichen Eingaben eine korrekte Ausgabe erzeugt. Ein Programm erhält (leider) nicht nur sinnvolle Eingaben, deshalb kann man sich nicht einfach darauf zurückziehen, nur einige wenige sinnvolle Eingaben zu testen. In einer URL sind 73 verschiedene Zeichen (die alphanumerischen Zeichen in Kleinund Großschrift sowie einige Sonderzeichen) erlaubt, alle weiteren Zeichen müssen URLkodiert werden. Würde man versuchen, alle URLs bis zu einer Länge von 20 Zeichen aufzuzählen (es gibt mehrere Sextillionen solcher URLs, das ist eine Zahl mit 37 Nullen), und könnte pro Sekunde eine Million URLs aufzählen, dann bräuchte man dafür rund Jahre. Das bedeutet in der Praxis, dass man diese Aufgabe niemals fertigstellen wird, da die Sonne in voraussichtlich 10 9 Jahren zu einer Supernova wird und dabei die Erde vernichtet. Durch Bildung von Äquivalenzklassen kann man die Anzahl der zu testenden Eingaben erheblich reduzieren. Unter einer Äquivalenzklasse versteht man eine Menge von Eingaben, für die der Programmablauf identisch ist, auch wenn mit anderen Variablen gerechnet wird. Nehmen wir an, Sie wollen ein Programm testen, das eine gegebene ganze Zahl inkrementiert. Es ist egal, ob dieses Programm eine Inkrement-Operation oder eine Addition verwendet (oder ganz anderes implementiert ist). Wenn wir davon ausgehen, dass PHP korrekt funktioniert, dann reicht es, eine einzige repräsentative Eingabe zu testen. Liefert das Programm für diese Eingabe ein richtiges Ergebnis, dann können wir davon ausgehen, dass es korrekt funktioniert, ohne dass wir es für alle ganzen Zahlen aufgerufen haben. Besondere Beachtung verdienen Grenzwerte und unzulässige Eingaben. Diese bilden neben den normalen Eingaben weitere Äquivalenzklassen, die ebenfalls jeweils einen Test erfordern. Was geschieht beispielsweise, wenn wir die höchste darstellbare Integer-Zahl inkrementieren? Und was geschieht, wenn wir versuchen, nichtnumerische Werte, beispielsweise eine Zeichenkette, zu inkrementieren? In der Praxis ist es nicht immer ganz einfach, die Äquivalenzklassen zu identifizieren beziehungsweise mit repräsentativen Eingaben zu testen. Als Faustregel gilt, dass man immer zuerst den Erfolgsfall, den sogenannten Happy Path, testen sollte. Danach widmet man sich Grenzwerten, also beispielsweise dem höchsten zulässigen Wert sowie dem höchsten zulässigen Wert plus eins beziehungsweise dem niedrigsten Wert und seinem Vorgänger. Nun kann man unsinnige Eingaben testen, etwa NULL-Werte oder falsche Datentypen. Für Black-Box-Tests ist das Identifizieren von Äquivalenzklassen schwieriger als für White- Box-Tests, bei denen man sich an den Fallunterscheidungen beziehungsweise den verschiedenen Ausführungspfaden orientieren kann. Da HTTP ein zustandsloses Protokoll ist, gibt es per Definition keinerlei Abhängigkeiten zwischen zwei aufeinanderfolgenden HTTP-Requests. Das Testen einer auf HTTP basierenden Anwendung scheint also wiederum besonders einfach, da jeder HTTP-Request, also jede Eingabe, nur ein einziges Mal getestet werden muss. Wie wir aber alle wissen, wird die Zustandslosigkeit von HTTP in den meisten Webanwendungen durch die Verwendung von Cookies und eine serverseitige Session-Verwaltung durchbrochen. Ohne einen Zustand könnte die Anwendung nicht zwischen einem anonymen und einem angemeldeten Benutzer unterscheiden, beziehungsweise man müsste die Zugangsdaten mit jedem HTTP-Request erneut übertragen. Da eine zustandsbehaftete Anwendung je nach ihrem Zustand unterschiedlich auf Eingaben reagieren kann, reicht es noch nicht einmal mehr aus, alle möglichen Eingaben zu

14 2.2 Systemtests 19 testen, obwohl wir schon wissen, dass es davon deutlich mehr gibt, als uns lieb sein kann. Um eine zustandsbehaftete Anwendung vollständig zu testen, müssten wir das Programm auch mit allen möglichen Abfolgen von Eingaben testen. Ein typisches Beispiel für zustandsabhängig variables Verhalten ist etwa der Versuch, auf nicht öffentliche Inhalte zuzugreifen. Ein anonymer Besucher wird aufgefordert, sich anzumelden, während ein angemeldeter Benutzer die entsprechenden Inhalte zu sehen bekommt, zumindest wenn er die dazu nötigen Berechtigungen besitzt. Es bedarf wohl keiner weiteren Überschlagsrechnungen, um zu zeigen, dass es unmöglich ist, einen umfassenden Test einer Webanwendung vor dem Weltuntergang zu Ende zu bringen, wenn es uns noch nicht einmal annähernd gelingt, in dieser Zeit alle möglichen Eingaben aufzuzählen. 2.2 Systemtests Testen im Browser Einer der großen Vorteile von PHP-Anwendungen ist, dass man gerade geschriebenen Code direkt ausführen und das Ergebnis im Browser ansehen kann. Dieses direkte Feedback ist vermutlich einer der Hauptgründe, warum viele Entwickler PHP gegenüber einer übersetzten Sprache wie Java bevorzugen. Was liegt also näher, als die Anwendung insgesamt im Browser zu testen? Heutzutage generieren PHP-Anwendungen längst nicht mehr nur statisches HTML. Mittels JavaScript kann im Browser der DOM-Baum des HTML nahezu beliebig manipuliert werden. So können jederzeit Seitenelemente geändert, hinzugefügt oder verborgen werden. In Verbindung mit asynchron abgesetzten HTTP-Requests an den Server, auf die als Antwort meist XML- oder JSON-Datenstrukturen zum Browser zurückgesendet werden, lässt sich das ansonsten nötige Neuladen der Seite vermeiden. Dank AJAX erlebt der Benutzer heute im Web teilweise einen Bedienkomfort, wie es bis vor einigen Jahren ausschließlich klassischen GUI-Anwendungen vorbehalten war. Durch den Einsatz von AJAX wird allerdings auch im Browser die Zustandslosigkeit des HTTP-Protokolls aufgehoben. Das dargestellte HTML-Dokument wird mehr und mehr zu einer eigenen Client-Anwendung, die über AJAX-Anfragen mit dem Server kommuniziert und ihren eigenen, technisch gesehen vom Server völlig unabhängigen Zustand hat. Der Programmierer sieht sich plötzlich mit zusätzlichen Aufgaben konfrontiert, die zuvor in der Webprogrammierung keine große Rolle gespielt haben, beispielsweise mit Locking- Problemen sowie dem Umgang mit Verklemmungen (englisch: Deadlocks) und Timeouts. Es genügt also in den meisten Fällen längst nicht mehr, das durch eine PHP-Anwendung generierte HTML-Dokument statisch zu analysieren, um die syntaktische Korrektheit beziehungsweise, wenn XHTML zum Einsatz kommt, die Wohlgeformtheit zu überprüfen und durch mehr oder minder aufwendiges Parsing sicherzustellen, dass die Seite (nur) die gewünschten Informationen enthält. Da heute ein zunehmender Teil der Funktionalität einer Anwendung in JavaScript implementiert wird, muss für einen umfassenden Test auch der JavaScript-Code ausgeführt wer-

15 20 2 Testen von Software den. Man könnte dazu eine JavaScript-Engine wie Rhino, SpiderMonkey oder V8 verwenden. Da man aber früher oder später auch die Darstellung der Seite überprüfen möchte, führt letztlich am Test im Browser kein Weg vorbei. Wie wir wissen, hat jede Browser- Familie beziehungsweise jede Browser-Version ihre Eigenheiten nicht nur bezüglich der Darstellung, sondern auch bezüglich der Ausführung von JavaScript-Code. Obwohl sich die Situation in den letzten Jahren deutlich gebessert hat, können die kleinen Browser- Unterschiede den Entwicklern einer Webanwendung das Leben ganz schön schwer machen. Verhält sich eine Anwendung im Browser-Test nicht wie erwartet, ist es oft nur schwer möglich, die tatsächliche Fehlerquelle zu lokalisieren. Ist das Problem auch in anderen Browsern vorhanden? Ändert sich das Verhalten eventuell mit anderen Sicherheitseinstellungen? Ist die Ursache des Fehlers ungültiges HTML oder ein Fehler im JavaScript- oder PHP- Code? Spielt etwa die Datenbank eine Rolle? Es ist ein generelles Problem von Systemtests, an denen naturgemäß viele Komponenten beteiligt sind, dass man die Ursache von Fehlern nur schwer einkreisen kann. Ein fehlgeschlagener Test, egal ob manuell oder automatisiert durchgeführt, zeigt zwar, dass die getestete Software nicht wie erwartet funktioniert, gibt aber keine Auskunft darüber, wo der Fehler liegen könnte. Im letzten Abschnitt wurde bereits ausgeführt, dass es unmöglich ist, eine Anwendung auch nur annähernd mit allen möglichen Eingaben zu testen. Selbst wenn wir uns darauf beschränken, alle Geschäftsvorfälle oder Geschäftsregeln mit jeweils einer repräsentativen Eingabe zu testen, erreichen wir schnell eine nicht mehr beherrschbare Komplexität. In einem sozialen Netzwerk muss beispielsweise jeder Freund den neuesten Blog-Eintrag eines Benutzers kommentieren dürfen. Kommt Moderation ins Spiel, dann darf ein Kommentar zunächst für niemanden sichtbar sein (außer vielleicht für den Moderator und den Autor des Kommentares), muss aber nach der Freischaltung sichtbar werden. Darf der Autor des Kommentares diesen nun löschen oder ändern? Muss eine Änderung erneut moderiert werden? Um Geschäftsregeln wie diese zu testen, müsste man sich abwechselnd mit mindestens zwei verschiedenen Benutzerkonten an der Anwendung anmelden. Selbst wenn man sich diese Mühe macht, steht man spätestens vor dem nächsten Release der Anwendung vor der Frage, ob man nun alle Tests wiederholen möchte oder einfach riskiert, dass die Anwendung aufgrund von unerwünschten Nebeneffekten einer Änderung nicht mehr wie erwartet funktioniert. Allein das Erstellen eines Testplanes, der beschreibt, welche Geschäftsvorfälle beziehungsweise Geschäftsregeln zu testen sind, welche Aktionen dazu notwendig und welche Ergebnisse zu erwarten sind, ist eine langwierige Arbeit. Auf der anderen Seite dient ein Testplan auch dazu, die funktionalen Anforderungen an die Anwendung zu dokumentieren. Der Testplan ist damit die Basis für Akzeptanztests, mit denen der Kunde prüft, ob die Software die an sie gestellten Anforderungen erfüllt Automatisierte Tests Da das manuelle Testen einer Anwendung zeitintensiv und nervenaufreibend ist, bietet es sich an, Tests so weit wie möglich zu automatisieren. Durch Automation wird nicht nur die

16 2.2 Systemtests 21 Ausführungsgeschwindigkeit erhöht, sondern auch Flüchtigkeitsfehler werden vermieden. Abgesehen vom Stromverbrauch entstehen keine Mehrkosten, wenn man die Tests wiederholt ausführt. Testautomation ist damit eine wichtige Voraussetzung, um Anwendungen mit verschiedenen Betriebssystemen, Datenbanken, PHP-Versionen und -Konfigurationen testen zu können. Ein erster Ansatz, Tests im Browser zu automatisieren, sind die sogenannten Capture and Replay -Werkzeuge. Im einfachsten Fall zeichnen diese die Mausbewegungen und Eingaben auf und können diese später wiedergeben. Da gerade Webanwendungen mit verschiedenen Fenstergrößen und Bildschirmauflösungen betrieben werden, sollte die Aufzeichnung nicht auf Bildschirmpositionen abstellen, sondern besser die im Browser ausgelösten Ereignisse auf DOM- beziehungsweise JavaScript-Ebene aufzeichnen. Die freie Software Selenium ist ein Werkzeug, das in Form einer Firefox-Erweiterung die Aufzeichnung und Ausführung von Browser-Tests ermöglicht. Ein in Java geschriebener Proxy-Server ermöglicht im Zusammenspiel mit PHPUnit auch die Fernsteuerung eines Browsers aus einem PHPUnit-Test. Somit können Browser-Tests auch im Rahmen von kontinuierlicher Integration ausgeführt werden. In den Selenium-Tests kann man mit Zusicherungen auf den DOM-Baum sicherstellen, dass die gerade dargestellte HTML-Seite bestimmten Prüfkriterien genügt. Da der Test direkt im Browser ausgeführt wird, wird der JavaScript-Code in der Seite ausgeführt, somit lassen sich auch AJAX-Anwendungen mit Selenium testen. In den Zusicherungen kann unter anderem das Vorhandensein oder der Inhalt beliebiger HTML-Elemente geprüft werden. Der Zugriff auf die einzelnen Elemente beziehungsweise DOM-Knoten erfolgt entweder über HTML-IDs, CSS-Selektoren, mittels JavaScript-Code oder mit einem XPath-Ausdruck. Da die Fernsteuerung des Browsers in JavaScript, das in die zu testende Seite injiziert wird, realisiert ist, gibt es beim Testen allerdings einige Einschränkungen, die auf Sicherheitsbeschränkungen zurückzuführen sind. Es ist beispielsweise nicht möglich, einen Datei-Upload zu testen, da dazu das im Browser ausgeführte JavaScript auf das Dateisystem des Rechners zugreifen müsste, um die hochzuladende Datei auszuwählen. Man möchte aus naheliegenden Gründen normalerweise nicht, dass der JavaScript-Code einer Website Zugriff auf das lokale Dateisystem hat. In manchen Browsern lassen sich Einschränkungen in speziellen Betriebsmodi umgehen. Firefox etwa kann man in den Chrome-Modus schalten, in dem deutlich weniger Sicherheitsbeschränkungen für JavaScript-Code gelten. Systemtests, die eine Anwendung durch die Benutzeroberfläche testen, sind wie alle indirekten Tests eher fragil. Eine scheinbar harmlose Änderung am Layout der Benutzeroberfläche, etwa weil die Werbung eines wichtigen Kunden prominent platziert werden muss, kann schon dafür sorgen, dass Zusicherungen fehlschlagen, obwohl eigentlich nur eine kosmetische Änderung an der Anwendung vorgenommen wurde. Es bedarf einiger Vorsicht und einer umsichtigen Planung sowohl der Seitenstruktur als auch der Zusicherungen, um vor zu häufig zerbrechenden Tests einigermaßen geschützt zu sein. Das Kapitel 17 enthält zahlreiche wertvolle Praxiserfahrungen zum Einsatz von Selenium. Fragile Tests sind auch ein Thema von Kapitel 4. In den meisten Fällen werden Sie Systemtests nicht gegen ein Live-System laufen lassen, schließlich wären die Benutzer vermutlich wenig begeistert darüber, wenn ihre Daten wie von Geisterhand geändert würden. Für manche Anwendungen ist es allerdings schwieriger, als man denkt, ein Testsystem aufzusetzen, etwa weil das Produktivsystem so komplex oder

17 Stichwortverzeichnis A Akzeptanztest 4, 23, 407, 432, 455 Allgegenwärtige Sprache 282, 285 Alternative PHP Cache (APC) 213, 449 Alternative PHP Debugger (APD) 213, 217 apd_set_pprof_trace() 218 pprofp 217 Apache Bench 204, 207 Apache HTTP Server 207, 212, 215 Äquivalenzklasse 18 Aufwärmphase 215 Ausführungspfad 24 B Backup 233 Barrierefreiheit 186 Benchmark 207 Build automatisierter 113 kontinuierlicher 110 Management 109 täglicher 110 Bytekit 13 C Caching 449 Cache Locking 207 Cache Miss 205 Cache Priming 205 Cache Warming 205 Call Graph 213, 217 Callee 217 Caller 217 Callgrind 213 Capability Maturity Model Integration (CMMI) 7 Carica CacheGrind 219 Change Risk Anti-Patterns (CRAP) Index 10 Code Smell Duplizierter Code 9, 85, 111, 283 Große Klasse 283 Lange Methode 283 Code-Altlasten 129, 434 Code-Coverage 10, 23, 145, 286, 301, 312 Path Coverage 23 Codeduplikat 111 Code-Review 113, 279 Coding Standard 13, 283 Collective Code Ownership Kollektives Eigentum CPU-Metrik 204 CPU-Zeit 204 Cross Site Request Forgery 242 Cross Site Scripting 245 D Data Set 151 Datenbanktest 141 Datenzugriffsschicht 450 DBUnit 146 Debug Build 206 Debugger 217, 219 Debugging-Symbole 215 Dependency Injection 9, 11, 28, 305, 445, 454 Dialog 183 Domain Specific Language (DSL) 426 Domain-Driven Design Domänengetriebenes Design Domänengetriebenes Design 285 E Entwurfsmuster Acceptor 446 Chain of Responsibility 449 Data Transfer Object 115 Decorator 152, 160 Multiton 304

18 468 Stichwortverzeichnis Observer 306, 447 Proxy 450 Repository 99 Singleton 304 Table Data Gateway 63 Visitor 446 extreme Programming 386 F Fehlbedienung 199 Fehlerbehandlung 235 Fehlertoleranz 199 Fixture 85 Flaschenhals 142, 203 Flood 211 Fluent Interface 315, 428 Funktion aufgerufene 217 Aufrufer 217 Funktionalität 4 FURPS 3 G GCC 215 Gebrauchstauglichkeit 4, 183 Gleitpunktzahl 324, 325 Global State 11, 91 gprof 222 H Happy Path 18 Hardening 231 Heatmap 200 HipHop 109 HTTPerf 211 HTTPLoad 204 Hudson 280 I Instrumentierung 212, 215 Integrationstest 458 Iteration 391 J JavaScript 194 Jenkins 14 JMeter 211 K KCachegrind 216, 217, 288 Keep It Simple, Stupid (KISS) 388 Klickdummy 183, 200 Kohäsion 12 Kollektives Eigentum 394 Konfiguration 108 Kontinuierliche Integration 110, 303, 340, 387, 410, 456 Kopplung 12, 235 L Lasttest 204, 206 Lime 309 Lines of Code 113 Comment 114 Executable 115 Non Comment 114 Lock 213 Logfile 200 M MacCallGrind 219 Memcache 205, 449 meminfo 204 Migration 143 Mock-Objekt 9, 11, 29, 30, 141, 146, 290, 323, 445 Model-View-Controller (MVC) 384 MySQL 143, 450 N Navigation 183 Nebenläufigkeit 207 Non-Mockable Total Recursive Cyclomatic Complexity 11 NPath-Komplexität 10, 24 O OProfile 213, 222 Optimierung 203 OWASP 238 P Pair Programming Programmieren in Paaren Partitionierung 385, 450 PEAR 436 Performanz 192, 203 Performanztest 203, 206 Persistenz 141 PHP_CodeBrowser 14 PHP_CodeSniffer 13, 281 phpcpd 13 PHP_Depend 13 php.ini 218

19 Stichwortverzeichnis 469 phploc 12 phpmd 13 PHPT 437 PHPUnit 12, 146, 286, 437 Selenium-Erweiterung 410 Planning Game 390 Port priveligierter 212 Profiler 204, 206, 212, 217, 219, 222 Profiling 204, 212 Programmieren in Paaren 393 Propel 109 Pylot 204, 209 Q Qualität externe 4, 31 interne 4, 31 Qualitätsmanagement 5 Qualitätssicherung konstruktive 7 R Reaktionsfreudigkeit 4 Rechteverwaltung 231 Redirect 352 Refaktorierung 5, 111, 283, 287, 308, 382 Regression 27 Regressionstest 179 Remote Procedure Call (RPC) 340 Representational State Transfer (REST) 340 Response Time 209 Root-Server 232 Runkit 435 S sar 204 Scrum 281, 388, 408, 454 Secure by Design 232 Security by Obscurity 234 Seiteneffekt 29 Selenium 21, 314, 384, 405 Selenium Grid 410 Selenium IDE 410 Selenium RC 409, 457 Separation of Concerns 235, 384 Server API (SAPI) 212 Serviceorientierte Architektur (SOA) 385, 450 Sharding 385, 450 Shared Hosting 232 Shared Memory 213 Sicherheit 4, 231 Siege 211 Single Responsibility Principle 9, 29 sismo 303 SOAP 340 Software Process Improvement and Capability Determination (SPICE) 7 Software-Artefakt 113 Software-Metrik 10, 112 Softwarequalitätsmodell 3 Softwaretestpyramide 31 Spaghetti-Code 434 Spike Solution 390 Sprint 454 Standup-Meeting 388 Story Point 391 Stub 29, 30, 141, 290 Suhosin 233 Symfony 109 Systemaufruf 215 Systemmetrik 204, 207 Systemtest 19 T Technische Schulden 5 Test automatisierter 109 Black-Box 17, 407, 434 Browserkompatibilitätstest 432 Capture&Replay 410 Edge-to-Edge 36, 40 End-to-End 31, 405 End-to-Test 4 Integration 36, 432 White-Box 17 Testautomatisierung 425 Testbarkeit 10, 29, 444, 451 Testdatenbank 166, 181 Test-First Programmierung 7 Testgetriebene Entwicklung 8, 26, 278, 388, 440 Testinventar 22, 142, 151, 166, 179, 181, 316, 415 Testisolation 22 Testplan 20 Test-Smell 84 Begieriger Test 86 Duplizierter Testcode 85 Fragiler Test 21, 89, 415, 417, 419 Indirekter Test 94 Konditionale Testlogik 100 Langsamer Test 98 Lügender Test 97 Mock-Overkill 103

20 470 Stichwortverzeichnis Obskurer Test 91 Selbstvalidierender Test 101 Skip-Epidemie 105 Undurchsichtiger Testname 95 Websurfender Test 102 Zusicherungsroulette 86 Testumgebung 205 Throughput 209 Timeboxing 458 Toleranzintervall 324 top 204 Trait 447 U Überwachung 231 Ubiquitous Language Allgegenwärtige Sprache Unit-Test 24 Usability 183 User Story 390 User-Test 200 V Valgrind 213, 222 Velocity 391, 458 Verfügbarkeit 4 Versionsmanagement 109 vfsstream 291 Virtualisierung 232 W Wasserfallmodell 457 WebDAV 357 Webdienst 195 Webgrind 219, 288 Webservice Webdienst White-Box-Test 24 X Xdebug 213, 217, 219, 286 xdebug.profiler_enable 219 xdebug.profiler_enable_trigger 219 xdebug.profiler_output_dir 219 XHProf 213, 219, 288 xhprof_disable() 221 xhprof_enable() 221 xhprof_html 221 xhprof_lib 221 xhprof.output_dir 221 XML-RPC 340 Y You Ain t Gonna Need It (YAGNI) 388 YSlow 192 Z Zend Extension 218 Zusicherung 27 Zuverlässigkeit 4 Zyklomatische Komplexität 10, 113