Motivation | ![]() |
In letzter Zeit fragen manche Leute, was denn der Unterschied sei zwischen:
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ß