2010-07-27 4 views
8

Ich habe ziemlich viel Wissen über Unit-Tests. Ich habe versucht, über Code-Verträge zu lesen. Hilft es wirklich Unit-Tests? Wird es überbewertet, besonders wenn wir über Code-Contract sprechen, der uns hilft, Komponententests durchzuführen? Ich beziehe mich speziell auf Verträge in .net 4.0. Ich benutze nunit für Unit-Tests.Helfen Code-Verträge wirklich beim Komponententesten?

Antwort

4

Ja und Nein. Komponententests sind im Grunde ein Vertrag, der besagt, dass MyMethod() X akzeptiert und erwartet, dass Y ein Ergebnis sein wird. Wenn dies nicht der Fall ist, schlagen Komponententests fehl und Sie werden als Entwickler von MyMethod() gewarnt etwas darin. Code-Verträge helfen Ihnen, Komponententests zu schreiben, weil die Anforderungen in den Verträgen es einfacher machen, die Anforderungen der Komponententests zu kennen, wenn Sie sie schreiben. Der wahre Grund für Code-Verträge liegt jedoch nicht bei Ihnen, sondern bei anderen Entwicklern, die die von Ihnen erstellte API verwenden. Komponententests geben Ihnen einen Überblick über die richtigen Ein- und Ausgänge. Wenn Sie jedoch Code in den freien Modus freigeben, werden Komponententests nicht mit der DLL-Datei freigegeben. Code-Verträge geben andere Entwickler den Vorteil, durch Compile-Time-Verträge und Überprüfung, die gleichen Anforderungen zu wissen. Verträge schützen vor jenen Entwicklern (mir), die eine schreckliche Tendenz haben, die Methodendokumentation nicht zu lesen und einfach nur Dinge in die Wege zu leiten, so dass sie jetzt aktiv durch Verträge gewarnt werden.

+0

Aber wird das nicht meine Logik duplizieren? Ich meine, wir haben die gleiche Logik (Vor- und Nachbedingungen) für Verträge und Unit-Tests. –

+1

Es sollte, und aus puristischer Sicht, sollte es, denn wenn jemand versehentlich den Vertrag entfernt, die Unit Tests würde immer noch die Logik verifizieren, dass Sie nicht wollen, dass es etwas tut, was es jetzt tun kann, oder umgekehrt. Die Verträge können ein Leitfaden für Schreibgeräte-Tests sein, sind aber kein Ersatz für sie. –

+0

Ich finde es schwer zuzustimmen, dass Verträge Unit-Tests duplizieren. Code-Verträge geben die Anforderungen an, Unit-Tests bestätigen ihre Gültigkeit. In gewissem Sinne bestätigen die Tests, dass Ihre Kontakte korrekt sind - Verträge sind lieferbarer Code und sollten daher getestet werden. –

0

Nein, ich glaube nicht, dass Codeverträge Ihnen helfen, Komponententests zu schreiben. Komponententests definieren das Verhalten und die Einschränkungen einer bestimmten Aktion. Eine der in den Komponententests beschriebenen Spezifikationen könnte sein, dass Argumente für eine Methode nicht null sein dürfen.

In diesem Fall müssen Sie immer noch den Komponententest schreiben. Der Code-Vertrag ist ein Weg, um Ihre Spezifikation zu implementieren, aber nicht der einzige Weg.

Mit anderen Worten, gehen Sie nicht davon aus, dass die Verwendung eines Codevertrags bedeutet, dass Sie keinen Komponententest schreiben müssen! Wenn jemand den Codevertrag ändert oder ihn entfernt, wird kein Test Ihnen mitteilen, dass die beabsichtigte Spezifikation fehlgeschlagen ist.

+4

Ich glaube nicht, dass irgendjemand sagte, dass Code-Verträge Unit-Tests ersetzen sollten. –

+0

Ich stimme zu, dass Verträge nicht dazu beitragen, Komponententests zu schreiben. Idealerweise sollten die Tests an erster Stelle stehen, so dass keine Verträge existieren sollten, bis ein Test fehlgeschlagen ist. Die Verträge können dann geschrieben werden, um irgendwelche negativen ("sollte werfen") Tests durchzusetzen. –

4

Code-Verträge können für Dinge verwendet werden, die nicht Unit-Tests (Verträge für Schnittstellen) verwenden können. Sie werden in Vererbungsketten angewendet (in denen Sie beim manuellen Komponententest leicht Fehler machen können). Sie stellen die Dokumentation automatisch bereit (etwas, was Unit-Tests nicht können). Sie können Laufzeitprüfungen in der Produktion bereitstellen (etwas, was Komponententests nicht können).

Auf der anderen Seite, Verträge scheitern nur, wenn sie ausgeübt werden, und so ohne Komponententests haben Sie keine Zusicherungen der Code-Qualität (d. H. Dass alle Ihre Code die verschiedenen Verträge erfüllt). Die beiden Konzepte sind komplementär.