Was ist eigentlich die Unit im Unit-Test?

[puddah]

Hallo zusammen,

ich praktiziere nun seid einer gewissen Zeit Test-First Entwicklung, und ich denke mittlerweile bin ich einigermaßen geübt. Ich stelle mir nur immerwieder die Frage, was genau die Unit in einem Unit-Test genau sein sollte. Ist dies immer eine durch Mocks und Stubs etc. isolierte Klasse oder ist es etwa eine "Einheit" sehr eng zusammenhängender Klassen oder etwa ein ganzes Modul in dem ich die Abhängigkeiten zu den "Sytemgrenzen" sprich Datenbank, GUI, Dateisystem, etc. abschneide? Ich persönlich habe die Erfahrung gemacht, dass Tests auf kleiner ebene zwar einfach zu schreiben sind, allerdings sehr wenig raum für refactorings lassen (bis auf umbenamsen von Variablen vielleicht). Tests auf sehr hoher Ebene allerdings lassen die Testsuites meist stark wachsen und die Tests werden unübersichtlich. Wo sollte man eurer Meinung nach die Grenze ziehen? Was ist die Unit beim Unit-Testen?

 

[Ebenius]

Ich zitiere da einfach mal aus der englischen Wikipedia:

In computer programming, unit testing is a method by which individual units of source code are tested to determine if they are fit for use. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual function or procedure. Unit tests are created by programmers or occasionally by white box testers.

Bei JUnit mache ich normaler Weise einen TestCase pro zu testender Klasse und in diesem pro zu testender Methode einen Unittest. Ergo heißt die Unit bei mir Methode.

Ebenius

 

[puddah]

Ok, pro Methode ist ein Test sicherlich ganz angebracht, ich häng den Test jetzt meistens auch nicht direkt an einer Methode auf, sondern an der Funktion, die ich Testen will, was bedeuten kann, dass ich mehrere Tests pro Methode hab, oder lediglich einen Test für eine Gruppe von Methoden. Aber die Frage ist, was ist die isolierte Unit, die ich teste. Sprich, mock ich wirklich alles, wovon die Klasse abhängt, oder aber sage ich dieser Satz an Klassen bildet meine modulare Einheit (unit) und dann mock ich nur noch was in diesem Context unwichtig oder schwer zu testen ist (wie z.B. Datenbank). Wie geht ihr da generell vor? Immer nur eine Klasse isoliert testen oder aber auch mal ein ganzes Subsystem?

 

[maki]

Die Unit wird festegelegt, wie du schon sagtest, aknn das eine Klasse oder ein ganzes Subsystem sein.
Wobei, eigentlich nennt man TEsts, die Systeme testen nicht mehr Unittest, sondern Integrationtest.
Anstatt Unit, sollte man das besser "SUT" (subject under test) nennen, denn damit muss man sich nicht gleich auf Unit bzw. Integrationstests festlegen.

 

[bygones]

Wie geht ihr da generell vor? Immer nur eine Klasse isoliert testen oder aber auch mal ein ganzes Subsystem?

sowohl als auch... im alltäglichen entwicklungsbetrieb die "reinen" UnitTests - also klassen/methoden isoliert. Durch den CI Server wird dann auch regelmäßig ganze Subsysteme getestet

 

[puddah]

Also ich denke auch, dass ein zusammenhängendes Subsystem auch als ganzes getestet werden sollte, alles andere macht in den meisten fällen auch garkeinen sinn. Integrationstests im CI fahren wir auch. Dies bezieht allerdings auch alle am System beteiligten Ressourcen mit ein (DB,Queues,etc.). Gibt es Argumente, die gegen ein solches vorgehen (also Tests für ein Subsystem und nicht genau für eine Klasse) sprechen?

 

[maki]

Man braucht beides, Integrationstests sind sog. "black box" tests und nicht so dolle für die sog. "defect localization", auch brauchen sie länger und werden deswegen nicht von jedem Entwickler ausgeführt.
Isolierte Unittests dagegen werden vom Entwickler geschrieben, oft auch bevor der zu testende Code geschrieben wurde, TDD eben.
Sie sind schnell, nutzen Mocks und haben eine sehr gute defect localization, gehören zu den "White Box" tests und werden oft ausgeführt vom Entwickler.

 

[bygones]

Isolierte Unittests dagegen werden vom Entwickler geschrieben, oft auch bevor der zu testende Code geschrieben wurde, TDD eben.
Sie sind schnell, nutzen Mocks und haben eine sehr gute defect localization, gehören zu den "White Box" tests und werden oft ausgeführt vom Entwickler.

was auch immer ein gutes Zeichen fuer falsche Tests an falscher Stelle ist, wenn die Entwickler mit Argument kommen die Tests dauern so lange.... Unittests sollten in bruchteil von sekunden durchlaufen, am besten sind dann Prinzipien wie "ich drueck auf speichern und die tests laufen los"

 

[puddah]

Was macht ihr denn jetzt meistens, immer genau eine Klasse testen und die Dependenzen mocken oder auch mal mehrere zusammen?

 

[Noctarius]

Das ist meiner Meinung nach schwierig zu sagen. Meistens teste ich Funktionen. Diese können aus einer Methode aber auch aus mehreren bestehen. Zur Not werden mehrere Tests in einem Testcase ausgeführt und so die komplette Hierarchie aufgebaut um auch in Einzelschritten zu testen.

 

[puddah]

am besten sind dann Prinzipien wie "ich drueck auf speichern und die tests laufen los"

da hilft dieses tool scheinbar ganz gut bei: Infinitest Improving Works