Warum ist das Testen von MVC Views verpönt?

Ich bereite gerade die Grundlagen für eine ASP.Net MVC-Anwendung vor und überlege, welche Art von Komponententests ich schreiben sollte. Ich habe an mehreren Stellen gesehen, dass die Leute im Wesentlichen sagten: "Machen Sie sich nicht die Mühe, Ihre Ansichten zu testen, es gibt keine Logik und es ist trivial und wird durch einen Integrationstest abgedeckt."

Ich verstehe nicht, wie dies zur anerkannten Weisheit geworden ist. Integrationstests dienen einem ganz anderen Zweck als Unit-Tests. Wenn ich etwas kaputt mache, möchte ich nicht eine halbe Stunde später wissen, wann meine Integrationstests kaputt gehen, ich möchte es sofort wissen.

Beispielszenario: Nehmen wir an, wir haben es mit einer Standard-CRUD-App mit einer Kundenentität zu tun. Der Kunde hat einen Namen und eine Adresse. Bei jeder Teststufe möchte ich sicherstellen, dass die Kundenabruflogik sowohl den Namen als auch die Adresse ordnungsgemäß abruft.

Um das Repository auf Unit-Tests zu testen, schreibe ich einen Integrationstest, um die Datenbank zu erreichen. Um die Geschäftsregeln auf Unit-Tests zu testen, verspotte ich das Repository, füttere die Geschäftsregeln mit den entsprechenden Daten und stelle sicher, dass meine erwarteten Ergebnisse zurückgegeben werden.

Was ich tun möchte: Um die Benutzeroberfläche einem Komponententest zu unterziehen, verspotte ich die Geschäftsregeln, richte meine erwartete Kundeninstanz ein, rendere die Ansicht und stelle sicher, dass die Ansicht die entsprechenden Werte für die von mir angegebene Instanz enthält.

Was ich nicht machen kann: Um das Repository zu testen, schreibe ich einen Integrationstest, richte ein entsprechendes Login ein, erstelle die erforderlichen Daten in der Datenbank, öffne einen Browser, navigiere zum Kunden und vergewissere mich, dass die resultierende Seite das entsprechende enthält Werte für die angegebene Instanz.

Mir ist klar, dass es Überschneidungen zwischen den beiden oben diskutierten Szenarien gibt, aber der Hauptunterschied ist die Zeit und der Aufwand, die erforderlich sind, um die Tests einzurichten und auszuführen.

Wenn ich (oder ein anderer Entwickler) das Adressfeld aus der Ansicht entferne, möchte ich nicht warten, bis der Integrationstest dies feststellt. Ich möchte in einem Unit-Test entdeckt und markiert werden, der mehrmals täglich durchgeführt wird.

Ich habe das Gefühl, dass ich ein Schlüsselkonzept einfach nicht verstehe. Kann jemand erklären, warum es eine schlechte Sache ist, ein sofortiges Test-Feedback zur Gültigkeit einer MVC-Ansicht zu erhalten? (oder wenn nicht schlecht, dann nicht der erwartete Weg, um besagtes Feedback zu bekommen)

Einfaches Testen der Benutzeroberfläche ist in ASP.NET MVC einfach genug. Im Wesentlichen müssen Sie nur bestätigen, dass der zurückgegebene HTML-Code die Elemente enthält, die Sie benötigen. Dadurch wird zwar sichergestellt, dass die HTML-Seite wie erwartet strukturiert ist, die Benutzeroberfläche wird jedoch nicht vollständig getestet.

Für einen ordnungsgemäßen Web-UI-Test ist ein Tool wie Selenium erforderlich, das Browser auf Ihrem Computer verwendet und sicherstellt, dass JavaScript und HTML in allen Browsern ordnungsgemäß funktionieren. Selenium verfügt über ein Client / Server-Modell, sodass Sie eine Reihe von virtuellen Maschinen mit Unix-, Mac- und Windows-Clients sowie die in diesen Umgebungen üblichen Browser verwenden können.

Nun setzt eine gut gestaltete MVC-Anwendung (Pattern, nicht Framework) die wichtige Logik in die Modelle und Controller ein. Kurz gesagt, die Funktionalität der Anwendung wird getestet, wenn Sie diese beiden Aspekte testen. Ansichten haben in der Regel nur eine Anzeigelogik und lassen sich leicht visuell überprüfen. Aufgrund der dünnen Verarbeitung in der Ansicht und des Großteils der gut getesteten Anwendung glauben viele Leute nicht, dass der Aufwand beim Testen der Ansichtsebene den durch sie erzielten Nutzen überwiegt.

Trotzdem hat MVC einige nette Möglichkeiten, um das von der Anfrage zurückgegebene DOM zu überprüfen. Dies reduziert die Schmerzen beim Testen der Ansichtsebene erheblich.

Ich würde nicht sagen, dass es verpönt ist. Diese Stimmung ist vielmehr das Ergebnis der Tatsache, dass das Testen von MVC-Ansichten (zumindest der aspx-Variante) in der Einheit ziemlich schwierig ist, da aspx-Ansichten zu stark von WebForms abhängig sind, die selbst nicht getestet werden können. Das Argument lautet also, dass sich die Mühe nicht lohnt , da die Ansichten in der Regel nicht so kompliziert sind.

Natürlich können Ansichten ziemlich kompliziert werden, so dass Sie die Wahl haben.

Ich bin mir nicht sicher, ob es verpönt ist. Die Testbarkeit ist einer der Hauptvorteile der Verwendung von ASP.NET MVC. Weitere Informationen hierzu finden Sie in Steve Sandersons Blog .

Er schrieb auch das zweifellos beste ASP.MVC-Buch (IMO). Er unterrichtet nicht nur MVC, sondern geht darüber hinaus, um Best Practices zu vermitteln, einschließlich Testverfahren.

Ich denke, ich muss ein wenig über Unit-Test-Ansichten klären - Sie können Unit-Tests auf der Grundlage des vom Controller zurückgegebenen Ergebnisses (ActionResult usw.) erstellen. Sie müssen noch andere Tests für die tatsächliche Interaktion zwischen Benutzeroberfläche und Benutzeroberfläche durchführen.

Sie erfahren, wie Sie die von einer Controller-Aktion zurückgegebene Ansicht testen, wie Sie die von einer Controller-Aktion zurückgegebenen Ansichtsdaten testen und wie Sie testen, ob eine Controller-Aktion Sie zu einer zweiten Controller-Aktion umleitet, indem Sie die folgende URL aufrufen: Beschreiben Sie in diesem kurzen Artikel das Testen von Ansichtsdaten in MVC .