Pourquoi voudriez-vous écrire des tests unitaires pour les contrôleurs?

Pour moi, c'est un test unitaire totalement hors de propos et je ne comprends pas pourquoi quelqu'un aurait passé du temps à l'écrire, car il y a très peu de valeur à en tirer. Je saurais parfaitement si ce contrôleur a renvoyé le type voulu en exécutant la méthode dans un navigateur. Vraiment, croyez-vous qu'un test est nécessaire pour cela et pourquoi?

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() );
    }
}

Leur point clé est ici:

Je saurais parfaitement si ce contrôleur a renvoyé le type voulu en exécutant la méthode dans un navigateur

Le test d'unité concerne l' automatisation des tests de non-régression de simples unités de code, pas que vous vous regardiez vous-même. Vous ne voulez pas faire vous-même les tests unitaires dans votre application.

EDIT: Ajout d'un commentaire @anotherdave:

Il s'agit de la facilité de mise à l'échelle. Tester un contrôleur dans un navigateur peut être OK; qu'en est-il de 10, 20, 50 contrôleurs? Vous écrirez le test une fois; vous devrez peut-être le mettre à jour lorsque vous changez le contrôleur, ce qui est une surcharge. Mais à quelle fréquence déployez-vous? Sûrement une vérification manuelle à chaque fois qu'il y a beaucoup plus de frais généraux que le test

Comme alternative à la réponse de @ Vladislav , les tests unitaires peuvent absolument être excessifs et vraiment indésirables. Si vous avez besoin de quelque chose de plus léger, vous pouvez effectuer des tests de non-régression de niveau supérieur en utilisant Selenium. Vous obtiendrez sûrement moins de couverture que les tests unitaires, mais vous pouvez obtenir une couverture raisonnable qui coûte beaucoup moins de temps à effectuer des tests unitaires et est plus flexible.

Autrement dit, si vous testez tout ce que vous avez, vous devez mettre à jour un ou plusieurs tests chaque fois que vous modifiez un élément simple.

Pourquoi voudriez-vous écrire des tests unitaires pour les contrôleurs?

Parce que sans connaître le contexte, vous ne pouvez pas dire avec certitude si vous devez tester ceci ou cela. Voici quelques raisons pour lesquelles vous voudrez peut-être tester les contrôleurs:

• le contrôleur peut contenir une logique de câblage de service complexe, qui est sujette aux erreurs. Les services eux-mêmes peuvent fonctionner correctement, c'est le résultat que vous souhaitez tester et pour une raison quelconque, vous avez envisagé de ne pas introduire la couche d'orchestration dans votre application
• vos contrôleurs contiennent TOUTE la logique commerciale de l'application et les contrôleurs sont en fait tout ce que vous POUVEZ tester (veuillez ne pas prétendre que toute votre vie vous avez travaillé avec des bases de code idéales, il y en a de telles, croyez-moi)
• votre équipe est composée de 99% de génies et 1% de personnes moyennes et vous voulez garder ce 1% hors des bogues dans leur salaire

Je suis entièrement d'accord avec l'OP.

Un test unitaire pour un contrôleur est inutile. Vous testez implicitement vos contrôleurs via des tests de régression (en utilisant Selenium par exemple).

Vous devez TDD tous les composants / objets que le contrôleur utilise et garder les contrôleurs aussi minces que possible. Ensuite, tout est correctement testé à l'unité. Ce dont vous voulez être certain, c'est que tout fonctionne bien ensemble lorsque vous effectuez des requêtes Web. Ce sont des tests de régression.