Unittests

nach \cite[S. 129ff.]{Goodliffe2006}

• Man glaubt schnell, dass der eigene Code funktioniert, wenn man ihn erneut liest (man liest, was man gemeint hat, nicht was der Code tut), aber man kann sich nur durch Tests sicher sein!
• Tests können nur vorhandene Fehler finden, nicht ihre Abwesenheit beweisen.
• Jedes Stück Code muss getestet werden (von dir selbst, denn niemand anderes wird es für dich tun)!
• Effektives Testen beginnt früh, damit Bugs schnell gefunden werden und nicht teuer werden.
• Schreibe Tests für jeden Fehler, den du findest.
• Führe die Tests so oft aus, wie es geht.
• Schreibe Tests für die unterschiedlichen Aspekte des Codes und nicht mehrere Tests, die dieselbe Funktion testen.
• Designe deinen Code, sodass er leicht zu testen ist.
• Führe automatische Tests als Teil des Builds aus.

• laut Gerard Meszaros \cite{Lippert2007} gibt es beim Entwickeln von Unit-Tests drei Arten von "Smells": Test, Behaviour und Project Smells
  • Test Smells sind offensichtlich im Code und "springen uns ins Gesicht" (z.B. doppelter Code oder ein Test, den "man nicht versteht")
  • Behaviour Smells sind Probleme beim Ausführen der Tests, die nicht direkt offensichtlich sind (z.B. schlägt ein Test beim ersten Mal fehl, danach ist er erfolgreich). Dies deutet meist auf Abhängigkeiten zwischen Tests hin.
  • Project Smells sind Probleme, die anderen Projektbeteiligten (nicht den Entwicklern) auffallen, also z.B. Bugs im Produktionscode. Die Ursachen sind meist organisatorischer Natur (z.B. Tests erzwungen ohne die Entwickler entsprechend zu schulen).
  • Smells sind immer nur ein "Symptom". Das eigentliche Problem ("root cause") muss dann ermittelt und behoben werden.
• Programmierer sind es gewohnt, "schwierigen" komplexen Code zu schreiben und übertragen das auf die Tests, die aber einfach sein müssen
• Conditionals und Loops gehören nicht in die Tests!
• wenn man Loops braucht, um Ergebnisse zu checken, sollte man hierfür eine eigene Assertion schreiben und den Code somit auslagern und wiederverwendbar machen
• zum Refaktorisieren von Testcode sind Tools wie Jester hilfreich, um vorher und nachher die Test Coverage zu prüfen
• das Schreiben von Tests sollte lediglich 10-20% der Arbeitszeit ausmachen (und nicht 90% weil sie so komplex sind)