Testgetriebene Entwicklung

Testgetriebene Entwicklung

Methode für agile Softwareentwicklung

Übersicht Themen

Wieso testen?TestartenWie viele Tests braucht man?Testgetriebenes EntwickelnKontinuierliche IntegrationBad-Practices & Test-SmellsTestrezepte

Gjero Krsteski13.04.2023 2

Wieso PHP-Projekte testen?

Gjero Krsteski13.04.2023 3

Verändernd

Hohes Tempo

NeueFunktionalitäten

Wieder-verwendung

Genauigkeit


Gjero Krsteski 4

Code nicht getestet = Code defekt

Code defekt = sehr teuer

13.04.2023


Gjero Krsteski 5

Entwickler testet nicht

Tag 1 Kunde entdeckt Bug

Kunde enttäuscht

Kunde meldet Bug

Tag 2Bug fix

Tag 3Backport

13.04.2023

Testarten

Black-Box-TestsTests, die ohne Kenntnis der Implementierung durchgeführt werden.

White-Box-TestsTests, die anhand des Quellcodes der zu testenden Anwendung entwickelt werden.

Gjero Krsteski 613.04.2023

Die Test-Pyramide

Gjero Krsteski 7

E-to-ETests

E-to-ETests

Functional TestsFunctional Tests

Unit TestsUnit Tests

Groß = SeleniumGroß =

Selenium

Mittel = Komponenten

Mittel = Komponenten

Klein = Code Einheit

Klein = Code Einheit

13.04.2023

Übersicht PHPUnit

Vorteileleicht erlernbar + erweiterbar + ausführbar

PraxisTestumgebung erstellenTest AufbauTest AbhängigkeitenTest Zusicherungen


Was sind Stub Objekte?

ersetzen Objekte oder Methoden mit Test-Dummysentkoppeln Code von externen Abhängigkeitenüberspringen langwierige Abläufe


Was sind Mock Objekte?

stellen wie Stubs Test-Dummys bereittesten, ob Methoden wie erwartet aufgerufen werdentesten die Kommunikation mit Komponenten, ohne einen tatsächlichen Aufruf loszutreten


Wie viele Tests braucht man?

Codeabdeckung von kritischen StellenMinimal - MaximaltestsGrenzwerteHappy Pathunzulässige Eingaben

kurzfristiger Code + keine Änderung + kein Test = OKCode -> Wiederverwendung = Code + Test = OK


Testgetriebene Entwicklung

Methode für agile Softwareentwicklung

Teil 2

Testgetriebenes Entwickeln

Vorteilesteigert die Produktivität von Programmieren

Verzicht auf spekulative FeaturesVerzicht auf zukünftig eventuell notwendige Spezialfälle

WichtigAuch wenn kein TE -> Tests immer am selben Tag wie Produktionscode schreiben!


Testgetriebenes Entwickeln – die Realität

Vermeiden durchType-Hints im Konstruktor & MethodenDependency InjectionInterfaces & AbstractsStatische Methoden vermeidenObjekte mit einziger & klar definierter Verantwortung


Testgetriebenes Entwickeln – das Mantra

Gjero Krsteski 15

RefaktoriereRefaktoriereEntferne jeden redundanten Code, der dafür erstellt

wurde, den Test zum Laufen zu bringen

GrünGrünSorge dafür, dass der Test schnellst möglich läuft, egal

was für Sünden du dafür begehen musst

RotRotSchreibe einen Test, der nicht funktioniert

13.04.2023

Testgetriebenes Entwickeln – Praxis

Aufgabe: TE1 – Teil 1 von 3Erstelle 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.



Aufgabe TE1 – Teil 2 von 3Das 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.



Aufgabe TE1 – Teil 3 von 3Erstelle eine neue Methode getValuePlusOne die den instanziierten Wert plus 1 zurückliefert. Teste das Verhalten der Methode getValuePlusOne mit Grenzwerten und unzulässige Eingaben.


Testgetriebenes Entwickeln – Refaktorierung

Die RegelnEntwickeln oder Refaktorieren, nie beides zugleich!Immer nur mit Unit-Tests zur AbsicherungDiszipliniert vorgehen in kleinen Schritten

Was genau Refaktorieren?Duplizierter Code => Risiken & MehrarbeitLange Methode => schwer zu verstehen & pflegenGroße Klasse => beschäftigt mit zu vielen Dingen, Verdacht auf duplizierten Code.


Was macht den Code nicht testbar?

Gott- Klassen & MethodenHart geschriebene AbhängigkeitenSachen privat machenLange MethodenLogik im KonstruktorStatische MehodenSingeltons


Test Strategien

Black-Box TestSelenium -> UnitTest + Refrakturierung

PfadfinderregelTagesende -> Test erstellen & aufräumen

Fixed-T-TimesFeste Zeiten in der Woche zum Testen


Kontinuierliche Integration

CodingKollektiver Besitz + TE + kont. Inspektion

TestenJeder Code hat UnitTestsTests schreiben -> Fehler beheben

DevOpsEntwicklung + Auslieferung = kein Big Bang


Danke für die Aufmerksamkeit!

Gjero Krsteski Web-Programmierer, Berater, Trainer

Homepage: krsteski.deE-Mail: [email protected]

Technology

Testgetriebene Entwicklung