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:
- er mit einer Datenbank kommuniziert.
- er über das Netzwerk kommuniziert.
- er das Dateisystem anspricht.
- er nicht zur gleichen Zeit wie ein anderer Unit-Test ausgeführt werden kann.
- 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.
