3. Wieso PHP-Projekte testen?
Verändernd
Genauigkeit Hohes Tempo
Wieder- Neue
verwendung Funktionalitäten
09.11.2011 Gjero Krsteski 3
4. Wieso PHP-Projekte testen?
Code nicht getestet = Code defekt
Code defekt = sehr teuer
09.11.2011 Gjero Krsteski 4
5. Wieso PHP-Projekte testen?
Entwickler
testet
nicht
Tag 1
Tag 3 Kunde
Backport entdeckt
Bug
Tag 2 Kunde
Bug fix enttäuscht
Kunde
meldet
Bug
09.11.2011 Gjero Krsteski 5
6. Testarten
Black-Box-Tests
Tests, die ohne Kenntnis der Implementierung
durchgeführt werden.
White-Box-Tests
Tests, die anhand des Quellcodes der zu testenden
Anwendung entwickelt werden.
09.11.2011 Gjero Krsteski 6
7. Die Test-Pyramide
Groß =
Selenium
E-to-E
Tests
Mittel =
Komponenten
Functional Tests
Klein =
Code Einheit
Unit Tests
09.11.2011 Gjero Krsteski 7
8. Übersicht PHPUnit
Vorteile
leicht erlernbar + erweiterbar + ausführbar
Praxis
Testumgebung erstellen
Test Aufbau
Test Abhängigkeiten
Test Zusicherungen
09.11.2011 Gjero Krsteski 8
9. Was sind Stub Objekte?
ersetzen Objekte oder Methoden mit Test-Dummys
entkoppeln Code von externen Abhängigkeiten
überspringen langwierige Abläufe
09.11.2011 Gjero Krsteski 9
10. Was sind Mock Objekte?
stellen wie Stubs Test-Dummys bereit
testen, ob Methoden wie erwartet aufgerufen werden
testen die Kommunikation mit Komponenten, ohne
einen tatsächlichen Aufruf loszutreten
09.11.2011 Gjero Krsteski 10
11. Wie viele Tests braucht man?
Codeabdeckung von kritischen Stellen
Minimal - Maximaltests
Grenzwerte
Happy Path
unzulässige Eingaben
kurzfristiger Code + keine Änderung + kein Test = OK
Code -> Wiederverwendung = Code + Test = OK
09.11.2011 Gjero Krsteski 11
13. Testgetriebenes Entwickeln
Vorteile
steigert die Produktivität von Programmieren
Verzicht auf spekulative Features
Verzicht auf zukünftig eventuell notwendige Spezialfälle
Wichtig
Auch wenn kein TE -> Tests immer am selben Tag wie
Produktionscode schreiben!
09.11.2011 Gjero Krsteski 13
14. Testgetriebenes Entwickeln – die Realität
Vermeiden durch
Type-Hints im Konstruktor & Methoden
Dependency Injection
Interfaces & Abstracts
Statische Methoden vermeiden
Objekte mit einziger & klar definierter Verantwortung
09.11.2011 Gjero Krsteski 14
15. Testgetriebenes Entwickeln – das Mantra
Rot
Schreibe einen Test, der nicht funktioniert
Grün
Sorge dafür, dass der Test schnellst möglich läuft, egal
was für Sünden du dafür begehen musst
Refaktoriere
Entferne jeden redundanten Code, der dafür erstellt
wurde, den Test zum Laufen zu bringen
09.11.2011 Gjero Krsteski 15
16. Testgetriebenes Entwickeln – Praxis
Aufgabe: TE1 – Teil 1 von 3
Erstelle ein Objekt Opposite, das beim Instanziieren, ein
Übergabeparameter vom Typ Integer bekommt. Erstelle
dafür eine Methode getValue, die den Gegensatz zu den
übergebenen Parameter liefert. Also bei 1 eine 0 und bei
0 eine 1.
Achtung: Ein Vorprozess sorgt dafür, dass das Objekt
immer eine 0 oder 1 beim Instanziieren bekommt.
09.11.2011 Gjero Krsteski 16
17. Testgetriebenes Entwickeln – Praxis
Aufgabe TE1 – Teil 2 von 3
Das Objekt Opposite soll in anderen Projekten
wiederverwendet werden. Der Vorprozess entfällt
somit. Sorge dafür, dass das Objekt Opposite und seine
getValue Methode weiterhin funktionieren und ein
entsprechenden Ausnahmefehler auslösen.
09.11.2011 Gjero Krsteski 17
18. Testgetriebenes Entwickeln – Praxis
Aufgabe TE1 – Teil 3 von 3
Erstelle eine neue Methode getValuePlusOne die den
instanziierten Wert plus 1 zurückliefert. Teste das
Verhalten der Methode getValuePlusOne mit
Grenzwerten und unzulässige Eingaben.
09.11.2011 Gjero Krsteski 18
19. Testgetriebenes Entwickeln – Refaktorierung
Die Regeln
Entwickeln oder Refaktorieren, nie beides zugleich!
Immer nur mit Unit-Tests zur Absicherung
Diszipliniert vorgehen in kleinen Schritten
Was genau Refaktorieren?
Duplizierter Code => Risiken & Mehrarbeit
Lange Methode => schwer zu verstehen & pflegen
Große Klasse => beschäftigt mit zu vielen Dingen,
Verdacht auf duplizierten Code.
09.11.2011 Gjero Krsteski 19
20. Was macht den Code nicht testbar?
Gott- Klassen & Methoden
Hart geschriebene Abhängigkeiten
Sachen privat machen
Lange Methoden
Logik im Konstruktor
Statische Mehoden
Singeltons
09.11.2011 Gjero Krsteski 20
21. Test Strategien
Black-Box Test
Selenium -> UnitTest + Refrakturierung
Pfadfinderregel
Tagesende -> Test erstellen & aufräumen
Fixed-T-Times
Feste Zeiten in der Woche zum Testen
09.11.2011 Gjero Krsteski 21
22. Kontinuierliche Integration
Coding
Kollektiver Besitz + TE + kont. Inspektion
Testen
Jeder Code hat UnitTests
Tests schreiben -> Fehler beheben
DevOps
Entwicklung + Auslieferung = kein Big Bang
09.11.2011 Gjero Krsteski 22