Normalerweise verstopft Ihr Controller verschiedene Objekte und verbindet sie in der richtigen Reihenfolge. Vielleicht ruft er ein Repository auf, liest einige Objekte und gibt sie durch die Rendermethode zurück. Vielleicht ruft er andere Handler/Manager, die Sachen machen.
Dies bedeutet, dass ein Controller eine Komponente auf hohem Niveau ist. Meistens bedeutet dies, dass Funktionstests anstelle von Komponententests in Ordnung sind. Sie sollten nicht darauf abzielen, mit Ihren Komponententests eine 100% ige Codeabdeckung zu erhalten. Vielleicht können Sie sich das so vorstellen: Wenn Sie alles testen, was der Controller aufruft (Modell, Validierung, Formular, Repository), was könnte schief gehen? Die meiste Zeit ist es etwas, das Sie nur beobachten, wenn Sie alle realen Klassen verwenden, die in der Produktion beteiligt sind.
Ich möchte auch darauf hinweisen, dass TDD nicht bedeutet, dass alles Unit-getestet werden muss. Es ist in Ordnung, einige Funktionstests für den High-Level-Code zu haben. Wie gesagt, wenn Sie die Low-Level-Komponenten mit Komponententests testen, sollten Sie nur testen, wie sie zusammenarbeiten, die Sie nicht mit Mocks testen können, weil Sie den Mocks sagen, was der Rückgabewert ist.
Wenn Ihr Controller mehr als nur Teile des Systems zusammenstellt, sollten Sie darüber nachdenken, das Zeug in mehr Low-Level-Klassen umzuwandeln, die Sie mit Unit-Tests testen können.
Also mein Vorschlag wäre, Funktionstests zu verwenden, um Ihre Controller zu testen und Unit-Tests zu verwenden, um Ihre Modelle und Ihre Geschäftslogik Zeug zu testen.
Was ist genau das Problem mit ihm ein 'Response' Objekt zurückkehrt? –
Nichts. Ich mag einfach nicht die Tatsache, dass ein Response-Objekt in einem Controller erstellt wird. Ich glaube fest an Dependency Injection, und ich hasse es, das "neue" Schlüsselwort in etwas anderem als einem DI-Container zu sehen. Vielleicht ist dieser Glaube falsch. –