Frage:
Was soll ein Unit-Test leisen?
- sollen sie so gestaltet werden, dass sie vom Fachbereich verstanden werden?
- oder eher technisch sein (also nur für Devs)?
Strukturierung von Tests
- Leerzeilen zwischen Given, When, Then
- State in Feldern "verstecken" vs. nur lokalen State (also globaler Felder vs. lokale Variablen)
BDD
- Cucumber/Gherkin (für viele Sprachen verfügbar)
- JBehave, JGiven: Java
- Testen über die UI oder Testen gegen das Domänen-Modell
UI-Tests und fachliche Tests trennen:
- ein Tests, der Navigationpfad prüft, aber keine Fachlichkeit
- anderer Test, der gegen Domänen-Modell Fachlichkeit prüft
-> wenn man nicht aufpasst, hat man auf einmal die Testpyramide auf den Kopf gestellt
Approval-Tests
- Textausgabe
- Screenshots (Snapshot-Testing)
Wann einsetzen?
"Um mal einen Fuß in die Tür bekommen, wenn man sonst keine bis wenig Tests hat: Ok"
Unterschied Approval-Tests und Tests mit handgeschriebene Assertions:
Test mit handgeschriebene Assertions haben eher zu wenig Assertions bzw. man muss noch weitere hinzufügen, damit ausreichend getestet wird.
Approval-Tests testen erstmal alles, also eher zu viel, da auch nicht relevante Dinge geprüft werden, so dass der Test ständig rot wird, auch, wenn noch alles funktioniert.
Snapshot-Tests: Bildvergleich
Property-based Tests vs. example-based Tests
- example-based Tests neigen zum Überspezifizieren
Anschaulichere Tests (Cucumber, Board-Darstellung bei GoL) können aus mehr Gründen kaputt gehen bzw.
nicht das testen, was man eigentlich will, da der Glue-Code/Parsing-Code falsch sein kann.
Tests sollten erklären, warum die Werte erwartet werden (sie also die richtigen sind).
Falls das nicht der Fall ist, dann sind sie eine Art Approval-Test.
Geschachtelte Tests und parametrisierte Tests
@Nested
in JUnit 5 oder describe
-> it
in RSpec oder JS-Testing-Frameworks
- geschachtelte Tests helfen die Unterschiede von Tests zu erkennen bzw. was eben komplett gleich ist
Warum schreiben wir fachliche Tests nicht immer in Cucumber und Co?
- zusätzlicher Aufwand (Given/When/Then-Sätze finden, Glue-Code schreiben, schwieriger zu refactoren)
- Aufwand lohnt sich vermutlich nur, wenn Nicht-Techniker beteiligt sind
BDD tools like Cucumber
Name des tests
- Aktive Formulierungen
- test name beschreibt das "Warum"
- Verschachteln von tests eine gute Idee?
Was macht tests lesbar
- Den lesbaren test gibt es nicht
- verwendetes tooling
- Vereinbarungen und Stil im Team
- ...
- Vermeide unnötige Details die keine Auswirkungen auf den test haben
- Zustand in Klassenfelder halten anstatt im Test durchzureichen (good thing)?
- Test enthält keine Details zur Implementierung
- technische details
- Hilfreiche assertion messages im Fehlerfall
- expected true but was false
- no message received