Warum würden Sie Komponententests für Steuerungen schreiben?

Für mich ist dies ein völlig irrelevanter Unit-Test und ich verstehe nicht, warum jemand Zeit damit verbracht hat, ihn zu schreiben, da es sehr wenig Wert gibt, davon zu profitieren. Ich würde sehr wohl wissen, ob dieser Controller den gewünschten Typ zurückgibt, indem er die Methode in einem Browser ausführt. Glauben Sie wirklich, dass hierfür ein Test erforderlich ist und warum?

public class ConstituencyControllerTests
{
    private ConstituencyController _constituencyController;
    private Mock<IConstituencyService> _IConstituencyServiceMock;

    public ConstituencyControllerTests() {
        _IConstituencyServiceMock = new Mock<IConstituencyService>();
    }

    [Test]
    public async Task I_Check_For_Return_Type_And_Result() {
        _constituencyController = new ConstituencyController( _IConstituencyServiceMock.Object );

        var result = await _constituencyController.Get();
        var content = ( (dynamic)result ).Content;

        Assert.IsEmpty( content );
        Assert.IsInstanceOf( typeof( System.Web.Http.Results.OkNegotiatedContentResult<IEnumerable<ListOfConstituencies>> ), result );
        _IConstituencyServiceMock.Verify( x => x.ListOfConstituencies(), Times.Once() );
    }
}

Der entscheidende Punkt ist hier:

Ich würde sehr wohl wissen, ob dieser Controller den gewünschten Typ zurückgibt, indem er die Methode in einem Browser ausführt

Beim Unit-Test geht es um die Automatisierung von Nicht-Regressionstests für einfache Code-Einheiten, nicht darum , wie Sie selbst aussehen. Sie möchten sich nicht immer selbst darum bemühen, Ihre Anwendung zu testen.

BEARBEITEN: @anotherdave Kommentar hinzufügen:

Es geht um einfache Skalierung. Das Testen eines Controllers in einem Browser ist möglicherweise in Ordnung. Was ist mit 10, 20, 50 Controllern? Du wirst den Test einmal schreiben; Möglicherweise müssen Sie es aktualisieren, wenn Sie den Controller ändern, was Overhead ist. Aber wie oft setzen Sie ein? Sicherlich eine manuelle Prüfung jedes Mal, wenn es viel mehr Aufwand gibt, als der Test

Als Alternative zu @ Vladislavs Antwort kann das Testen von Einheiten absolut alles ein Overkill sein und wirklich unerwünscht. Wenn Sie etwas Leichteres benötigen, können Sie mithilfe von Selen einen Nicht-Regressionstest auf höherer Ebene durchführen. Sicherlich erhalten Sie weniger Deckung als Unit-Tests, aber Sie können eine raisonable Deckung erhalten, die viel weniger Zeit für Unit-Tests kostet und flexibler ist.

Wenn Sie also alle Komponenten testen, müssen Sie bei jeder Änderung eines einfachen Elements einen oder mehrere Tests aktualisieren.

Warum würden Sie Komponententests für Steuerungen schreiben?

Denn ohne den Kontext zu kennen, kann man nicht sicher sagen, ob man dies oder jenes testen muss. Hier sind einige Gründe, warum Sie Controller testen möchten:

• Der Controller enthält möglicherweise eine komplexe Dienstverdrahtungslogik, die fehleranfällig ist. Die Dienste selbst funktionieren möglicherweise einwandfrei. Dies ist das Ergebnis, das Sie testen möchten, und aus irgendeinem Grund haben Sie in Erwägung gezogen, keine Orchestrierungsschicht in Ihre App einzuführen
• Ihre Controller enthalten DIE GANZE Geschäftslogik der Anwendung und Controller sind eigentlich alles, was Sie testen können.
• Ihr Team besteht zu 99% aus Genies und zu 1% aus Durchschnittsleuten, und Sie möchten, dass diese 1% nicht zu Fehlern in ihrem Gehalt werden

Ich stimme dem OP voll und ganz zu.

Ein Komponententest für eine Steuerung ist sinnlos. Sie testen Ihre Controller implizit über Regressionstests (z. B. mit Selen).

Sie sollten alle Komponenten / Objekte, die der Controller verwendet, einem TDD unterziehen und die Controller so dünn wie möglich halten. Dann wird alles richtig gerätetestet. Sie möchten sicher sein, dass bei der Ausführung von Webanfragen alles gut zusammenarbeitet. Das sind Regressionstests.