Motivation

In letzter Zeit fragen manche Leute, was denn der Unterschied sei zwischen:

• Verwendung von Asserts, siehe z. B. IstAssertSinnvoll
• UnitTests
• DesignByContract

Assert

Assert ist ein Mittel, um zu prüfen, ob etwas gilt, von dem man annimmt, dass es gilt.

UnitTests

UnitTests testen einzelne Einheiten von Software, das können zum Beispiel Klassen oder Komponenten sein. UnitTests verwenden Asserts im Testfallcode, um festzustellen, ob die zu testende Unit auch mit den Ergebnissen reagiert, mit denen sie reagieren müsste (Soll-Ist-Vergleich). So arbeitet zum Beispiel das bekannte Unit-Testing-Framework JUnit von Gamma et al.

DesignByContract

DesignByContract prüft Vorbedingungen und sichert Nachbedingungen einer Methode zu. Dieser Prüfvorgang kann entweder in der Programmiersprache selbst fest eingebaut sein (z. B. in Eiffel von BertrandMeyer) oder aber mit Hilfe von Asserts in anderen Sprachen (Java, C++, etc.) nachgebildet werden. Diese Prüfungen passieren dann in der Methode selbst, nicht außerhalb.

Metapher

Asserts in Methoden sind Bollwerke gegen Fehlbenutzung. UnitTests können Angriffe auf diese Bollwerke sein, um zu sehen, ob sie standhalten. DesignByContract ist eine Designphilosophie, die Bollwerke so wichtig findet, dass sie häufig benutzt werden.

Diskussion

Nach meinem Gefühl gibt es einen entscheidenden psychischen Unterschied zwischen DesignByContract und UnitTests (insbesondere in Hinsicht auf TestgetriebeneEntwicklung):

- eine Methode ohne precondition garantiert, unter allen Umständen zu funktionieren - das Hinzufügen von preconditions schränkt die Benutzung einer Methode ein. Das heißt, beim Formulieren von preconditions werde ich im wesentlichen dazu animiert darüber nachzudenken, wie die Methode nicht benutzt werden soll.

- eine Methode ganz ohne Tests garantiert keinerlei Funktionalität - das Hinzufügen von UnitTests im Zuge testgetriebener Entwicklung erweitert in den meisten Fällen die Anwendbarkeit einer Methode. Beim Formulieren von UnitTests konzentriere ich mich also im wesentlichen darauf, wie die Methode tatsächlich verwendet werden soll.

Obwohl sich also TestgetriebeneEntwicklung und DesignByContract nicht unbedingt gegenseitig ausschließen, empfinde ich sie von der dahinter stehenden Geisteshaltung als doch sehr unterschiedlich - TGE gibt mir ein sehr konstruktives Gefühl, während mir die Anwendung von DBC eher defensiv vorkommt... -- IljaPreuß

Tu nur das nötige ... manchmal muss eine Methode eben nicht den gesamten Eingaberaum abdecken, Auch in TGE gibt es Fehlerbehandlung für solche Fälle. Mit Asserts steht die Fehlerbehandlung eben an einer definierten Stelle (Anfang oder Ende einer Methode). Ich denke das ist keine Frage der Geisteshaltung sondern DBC und TGE sind einfach unterschiedliche Mittel, die man jeweils im passenden Fall einsetzen kann. -- mj