Benutzer-Werkzeuge
se:unittests
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
|
se:unittests [2009-01-30 14:55] stefan |
se:unittests [2010-05-05 13:32] stefan |
||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| ====== Unittests ====== | ====== Unittests ====== | ||
| - | **nach {[quellen:Goodliffe2008|S. 129ff.]}** | + | **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! | * 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. | * Tests können nur vorhandene Fehler finden, nicht ihre Abwesenheit beweisen. | ||
| Zeile 11: | Zeile 11: | ||
| * Führe automatische Tests als Teil des Builds aus. | * Führe automatische Tests als Teil des Builds aus. | ||
| + | ===== Test-Smells und Refactoring von Test-Code ===== | ||
| + | * 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 [[http://jester.sourceforge.net/|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) | ||
se/unittests.txt · Zuletzt geändert: 2014-04-05 11:42 (Externe Bearbeitung)
Seiten-Werkzeuge
Falls nicht anders bezeichnet, ist der Inhalt dieses Wikis unter der folgenden Lizenz veröffentlicht: CC Attribution-Noncommercial-Share Alike 4.0 International
