Wer sollte die Unit Tests schreiben, der, der den Code geschrieben hat oder sein Kollege?
-
Frage siehe Titel.
-
Idealerweise beide.
Der der den Code geschrieben hat, weiss wo er diverse Sonderfälle berücksichtigt hat, und kann daher Unit-Tests schreiben die diese Sonderfälle abklopfen.
Weiters tut er sich viel leichter dabei Whitebox-Tests zu schreiben.Dafür denkt derjenige der den Code geschrieben hat oft auch beim Tests schreiben genau nicht an die Sonderfälle, die er schon beim Code Schreiben übersehen hat. Und wird daher auch kaum Tests schreiben die das aufdecken. Daher sollte er besser nicht der einzige sein der Tests schreibt. Ein weiterer Grund dafür: Es gibt Leute die das als kleinen Wettbewerb sehen, an dem sie Spass haben. Nach dem Motto: Wessen Tests finden mehr Fehler - meine Tests in deinem Code oder deine Tests in meinem Code? Und dass "intrinsische" Motivation (Spass) die Resultate verbessert sollte denke ich bekannt sein.
-
Bei uns:
Beim Pairing: der andere.
Ansonsten: derselbe, aber mit TDD. Integrationstests/Systemtests dann aber wieder jemand anderes.MfG SideWinder
-
@SideWinder
Wie ist bei euch das Verhältnis whitebox vs. blackbox bei Unit-Tests? (Bzw. allgemein bei Tests.)
-
hustbaer schrieb:
Idealerweise beide.
Der der den Code geschrieben hat, weiss wo er diverse Sonderfälle berücksichtigt hat, und kann daher Unit-Tests schreiben die diese Sonderfälle abklopfen.
Weiters tut er sich viel leichter dabei Whitebox-Tests zu schreiben.Dafür denkt derjenige der den Code geschrieben hat oft auch beim Tests schreiben genau nicht an die Sonderfälle, die er schon beim Code Schreiben übersehen hat. Und wird daher auch kaum Tests schreiben die das aufdecken. Daher sollte er besser nicht der einzige sein der Tests schreibt. Ein weiterer Grund dafür: Es gibt Leute die das als kleinen Wettbewerb sehen, an dem sie Spass haben. Nach dem Motto: Wessen Tests finden mehr Fehler - meine Tests in deinem Code oder deine Tests in meinem Code? Und dass "intrinsische" Motivation (Spass) die Resultate verbessert sollte denke ich bekannt sein.
Wenn man doppelte Arbeit vermeiden möchte und nicht möchte, das zwei Unit Tests das gleiche abdecken, wer sollte dann von den beiden den Unit Test zu erst schreiben?
Der, der den Code geschrieben hat, weil er weiß, was da auf jeden Fall rein muss oder der, der den Code nicht kennt?
-
Gute Frage. Aus Erfahrung kann ich dazu nix sagen. Ich würde es aber so machen wie du schreibst, also erstmal den der auch den Code schreibt die ersten Tests schreiben lassen.
Weil er die Tests schon gut brauchen kann während der Entwicklung. Und wenn er sie selbst schreibt vermeidet das u.A. unnötige Verzögerungen. Auf jeden Fall ist es hilfreich wenn man die Tests schon vor bzw. während der Entwicklung hat, und da einem während der Entwicklung immer wieder "test-würdige" Dinge auffallen an die man vorher nicht gedacht hat, ist es kaum möglich vorab alle sinnvollen Tests zu schreiben.----
Und... hat zwar nix direkt mit deiner Frage zu tun, aber weil's mir beim Thema automatisierte Tests gerade einfällt: Wenn ein Bug für eine freigegebene Version gelemdet wird, dann heisst das oft dass es noch keinen Test gibt der diesen Bug "aufdeckt". Sonst wäre er normalerweise ja bereits gefixt worden. In dem Fall sollte man erstmal mindestens einen neuen Test schreiben, der diesen Bug "findet", und dann erst den Bug fixen. Verringert die Chance für Regressions. Und Regressions gehören mMn. zu den wirklich nervigen und unangenehmen Dingen.
-
hustbaer schrieb:
@SideWinder
Wie ist bei euch das Verhältnis whitebox vs. blackbox bei Unit-Tests? (Bzw. allgemein bei Tests.)Bei unit tests einzelner Klassen sind wir whiteboxy unterwegs, aber wir versuchen in letzter Zeit immer größere Komponenten zu testen (diese dann blackbox) damit wir mehr Spielraum für Refactorings haben ohne Tests dabei anpassen zu müssen. Gute Input-Output-Blackbox-Tests für ganze Komponenten haben sich da bei uns sehr gut bewährt. Die gestalten wir dann auch gerne integrativer und mocken nicht alles weg, das führt zu lesbareren und wartbareren Tests die zusätzlich auch noch mehr Sicherheit bieten (wie immer wenn man integrativer unterwegs ist).
Man muss dann halt schauen, dass man die internen Utilities dieser Komponenten nicht irgendwo anders blind wiederverwendet. Da muss man rigide sein: wird etwas anderes als auf dem Level einer solchen Komponente wiederverwendet, muss man sich hinsetzen und das Utility oder was auch immer mit "echten" Unit-Tests ausstatten.
MfG SideWinder
