Wenn Sie eine Anwendung mit den Code-Verträgen entwickeln, wissen Sie vielleicht, dass dieses Konzept in der Programmiersprache Eiffel eingeführt wurde.Sind Unit-Tests erforderlich, wenn Sie Code-Verträge haben?
Ich bin sehr verwirrt geworden, nachdem ich dieses Konzept in meiner C# -Anwendung unter Verwendung System.Diagnostics.Contracts versucht habe.
Die Hauptfrage ist für mich der nächste:
sind wirklich Einheit-Tests erforderlich, wenn Sie Code Verträge haben?
Einer der wichtigsten Unterschiede, dass Unit-Test-Frameworks in der Regel nicht bietet, ist die Möglichkeit, private Methoden zu nennen (außer MS fakes Bibliothek mit ihrer shims). Es ist getan, wegen der Unterstützung der Zusammensetzung & die Idee, dass private Methoden durch öffentliche Methodenaufrufe abgedeckt sind.
Wie für die Code-Verträge kann ich Contract.Requires, Contract.Ensures für private Methoden deklarieren.
Also, warum brauche ich Komponententests, wenn ich Code-Verträge habe, deren Verhalten sehr ähnlich ist.
Danke
Können Sie einen Code-Vertrag für jeden Aspekt schreiben, den Sie jemals testen möchten? Und ist das Vertragssystem in der Lage, jeden dieser Verträge (zur Erstellungszeit) zu überprüfen? Das klingt unwahrscheinlich für mich. –
@JonSkeet Ich nehme an, dass, wenn ich ein Produkt ohne Bugs haben will (in bestimmten Versionen) - muss ich einen sehr hohen Prozentsatz an Code abdecken. Was also Unit-Testing betrifft (wo ich immer versuche, 100% zu erreichen), versuche ich, das gleiche für die Code-Verträge zu tun. Auch TDD-Verhalten (bei jedem Zyklus R-> G-> R) setzt voraus, dass man den Clean-Code für jedes Ziel einzeln entwickelt, man kann nicht zu einem anderen Zeug wechseln, wenn man das vorhergehende nicht beendet hat, oder? –
Ich betrachte die Codeabdeckung nicht als besonders gute Proxy-Metrik für die Codequalität, um ehrlich zu sein. Es ist möglich, 100% Codeabdeckung zu haben, ohne wirklich über Eckfälle nachzudenken. –