Sollen Controller in MVC-Webanwendungen Unit-testbar sein?

Question

Es scheint mir, dass Webentwickler verschiedener Programmiersprachen oft unterschiedliche Meinungen dazu teilen. Zum Beispiel scheinen Webentwickler von Ruby (bei denen Rails das vorherrschende Framework ist) Controller als Glue-Code zu betrachten, der Funktionstests, aber keine Komponententests haben sollte. Eine ähnliche Einstellung dominiert in der PHP-Welt, aber es gab einige Initiativen (z. B. Symfony2).

Allerdings scheint es auch, dass zum Beispiel einige ASP.NET MVC-Entwickler tatsächlich want their controllersto be unit-testable.

Was ich gerne wissen würde ist, ob das tatsächlich in der Webentwicklung funktioniert. Sind Controller einen Unit-Test wert? Beeinflusst das Design, das sie Unit-testbar sind, die Entwicklungsgeschwindigkeit in nicht-trivialen Anwendungen merklich? Haben auch irgendwelche Web-Frameworks versucht, Controller-Unit-Testbarkeit zu erzwingen? Persönliche Erfahrungen sind willkommen.

Answer 1

Alles ist es wert, getestet zu werden. In diesem Fall hängt es davon ab, wie viel von der Logik in den Controllern realisiert wird ... In einem kleinen Projekt kann keine externe Logik angehängt werden und Sie möchten einige der Datenbankoperationen in Ihrem Controller durchführen (wie bei vielen Microsoft-Beispielen) . In größeren Lösungen müssen Sie den Controller möglicherweise nicht testen, solange es nur bestimmte Business-Logik-Methoden aufruft ... Es geht nicht darum, ob Controller es wert sind, Unit-getestet zu werden, es geht darum, ob der Code in ihnen enthalten ist.

Answer 2

Kurze Antwort: "Ja" mit einem "Wenn", lange Antwort: "Nein" mit einem "Aber".

Heutzutage tendiere ich dazu, Controller-Level-Komponententests zugunsten einer starken Unit-Test-Abdeckung von Modellen und Geschäftsobjekten und einer funktionalen Testabdeckung mit Cucumber zu verpassen. Die Annahme hier ist, dass die Controller sehr leichte Objekte sind, die Daten in zugrunde liegende Modelle leiten, die die große Mehrheit der Geschäftslogik einkapseln.

Allerdings tendiere ich immer noch dazu, einige der Kontrollflüsse auf der Controller-Ebene sehr leicht zu erfassen. Es tendiert dazu, eher eine Plausibilitätsprüfung zu sein.

Eines der Probleme beim Testen auf Controller-Ebene ist, dass Sie oft eine große Anzahl von Modellen und Objekten nachahmen oder generieren müssen, um effektiv zu testen. Angesichts dessen empfinde ich es als wertvoller, diese Tests in die funktionalen Schichten zu überführen, wo der Teststil es ermöglicht, diese Abhängigkeiten effizienter auszudrücken (entweder durch explizites Befolgen der Schritte, die erforderlich sind, um sie durch Ihre Anwendung selbst oder durch ein System zu generieren Die deklarativen Regeln der Gurke).

Answer 3

Eine der besten Eigenschaften des MVC-Musters ist, dass die Controller isoliert von der HTML-Ausgabe von den Ansichten getestet werden können. Seiten, die die Logik mit der HTML-Ausgabe mischen, sind schwer zu testen, und dies ist eines der Probleme, die MVC löst - es macht Ihren Controller komplett auf Logik und Sie können es testen, ohne HTML zu analysieren.

Idealerweise erhält Ihr Controller Daten aus separaten Datenzugriffsklassen, die Sie für Ihre Tests ausstellen können, sodass Sie nur die Logik testen. Im Wesentlichen isolieren Sie Ihren Controller von der Datenbank auf die gleiche Weise wie MVC ihn von der View isoliert - dann sind die Tests einfach, da Sie auch keine Datenbank mit Testdaten benötigen.