Die acht Eigenschaften guter Unit-Tests

Bei meinen Recherchen im Rahmen meiner Masterarbeit zum Thema “Test Driven Development als Maßnahme zur Qualitätssicherung bei der Softwareentwicklung” habe ich versucht, herauszufinden, welche Eigenschaften “gute” Unit-Tests aufweisen sollten. Herausgekommen ist die folgende Liste aus acht Eigenschaften, für die ich leider auch nach mehreren Versuchen mit unterschiedlichen Wörtern kein leicht zu merkendes Akronym finden konnte:

  • korrekt: Die Test müssen in sich fehlerfrei sein und zu den Anforderungen passen.
  • schnell: Die Tests müssen schnell laufen, um häufig durchgeführt werden zu können.
  • abgeschlossen: Die Tests müssen ein klares Ergebnis liefern und dürfen keine Interpretation benötigen.
  • isoliert: Die Tests müssen unabhängig von anderen Tests durchführbar sein und dürfen andere Tests nicht beeinflussen.
  • sprechend: Die Tests sollten ihre Absicht durch sprechende Benennung kundtun (wie etwa beim BDD).
  • wartbar: Die Tests sollten den Regeln für sauberen Code folgen und sich leicht an den veränderten Produktivcode anpassen lassen.
  • begrenzt: Die Tests sollten jeweils nur einen kleinen Bereich des Testobjekts prüfen (und nicht etwa mehrere Methoden gleichzeitig).
  • einfach durchführbar: Die Tests müssen so einfach wie möglich (am besten auf Knopfdruck) durch einen beliebigen Entwickler durchführbar sein.

Wer hat noch mehr zu bieten?

Quellen

Über Stefan

Polyglot Clean Code Developer

2 Kommentare

  1. Markus
    2. September 2009 um 9:16:06

    Moin,

    schnell sehe ich etwas zwiespältig. Natürlich sollten die Tests schnell laufen, aber wenn das System größer und komplexer wird, ist einfach die Masse so groß, dass die Tests sehr lange laufen.

    Deshalb finde ich den Ansatz von TestNG sehr gut. Dort kann man die Tests gruppieren. Beim starten der Tests kann man die gewünschte Gruppe angeben und nur die Tests die der Gruppe sind, werden durchlaufen.

    Man muss also nicht immer die komplette Test-Suite durchlaufen, wenn man etwas einchecken will, sondern einen guten Querschnitt. Wie man diesen Querschnitt findet, sprich die Test gruppiert, steht auf eine anderem Blatt.

    Ein kompletten Durchlauf der Test-Suite sollte maschinell durch ein continuous integration Tool gemacht werden.

    Gruß
    Markus

  2. Stefan
    2. September 2009 um 10:30:40

    @Markus: Für das Test Driven Development sind schnelle Unit-Tests unabdingbar. Man kann nicht vor jedem kleinen Refactoring 10 Sekunden warten.

    Die Möglichkeit der Test-Gruppierung ist daher auf jeden Fall sinnvoll, um während der (testgetriebenen) Entwicklung nur die Tests laufen zu lassen, die das zu ändernde Modul betreffen. Allerdings sollten danach durchaus mehrmals am Tag alle Tests ausgeführt werden. Dabei spielt die Zeit dann keine so große Rolle mehr.

    In NUnit ist die Möglichkeit der Gruppierung z.B. schon direkt eingebaut. Man kann einfach über das Attribut “Category” Kategorien angeben, auf die der TestRunner dann eingeschränkt werden kann.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks: 

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax