Wann ist ein Test ein Unit-Test?

Standard

Entwickler schreiben ihre Tests normalerweise mit einem Unit-Test-Framework. Oft sind die Tests aber langsam und unlesbar. Fast immer liegt es daran, dass die Tests mit der Datenbank, dem Dateisystem, einem Web-Service oder einer anderen externen Ressource kommunizieren. Die Entwickler hören zuerst auf, die Tests regelmäßig auszuführen, und in weiterer Folge schreiben sie auch keine Tests mehr, weil “Unit-Tests” so langsam und schwer zu ändern sind.

Michael Feathers hat schon im September 2005 die Kriterien für Unit-Tests zusammengefasst:

“Ein Test ist kein Unit-Test, wenn:

  1. er mit einer Datenbank kommuniziert.
  2. er über das Netzwerk kommuniziert.
  3. er das Dateisystem anspricht.
  4. er nicht zur gleichen Zeit wie ein anderer Unit-Test ausgeführt
    werden kann.
  5. du spezielle Dinge mit dem Environment tun musst (z.B. Editieren
    von Konfigurationsdateien), um ihn auszuführen.

Tests, die diese Dinge machen, sind nicht schlecht. Häufig sind sie es
wert, geschrieben zu werden, und dafür kann ein Unit-Test-Harness
verwendet werden. Aber es ist wichtig, sie von echten Unit-Tests
trennen zu können, so dass wir eine Reihe von Tests haben, die wir
schnell ausführen können, wann immer wir unseren Code ändern.”

Entwickler schreiben also häufig gar keine Unit-Tests! Stattdessen handelt es sich um Integrationstests. Um echte Unit-Tests zu schreiben, gehört also mehr dazu als die Test-Attribute des verwendeten Unit-Test-Frameworks zu kennen.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>