Softwerkskammer

 

Lesbare Tests

Frage:
Was soll ein Unit-Test leisten?

  • 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 testen erstmal nichts, was geprüft werden soll wird Stück für Stück (Assertion für Assertion) ergänzt (eher Gefahr von false negatives).
Approval-Tests testen erstmal alles, also eventuell/eher zu viel, da auch nicht relevante Dinge geprüft werden, so dass der Test ständig rot wird, auch, wenn noch alles funktioniert (eher Gefahr von false positives).

Snapshot-Tests: Bildvergleich

  • BackstopJS

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
  • Ohne Kontextwechsel (Produktivcode und Testcode in der gleichen (Programmier-)Sprache) effizienter

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

 

Aktivitäten