Pourquoi le test des vues MVC est-il mal vu?


23

Je suis actuellement en train de préparer le terrain pour une application ASP.Net MVC et j'examine le type de tests unitaires que je devrais être prêt à écrire. J'ai vu à plusieurs endroits des gens dire essentiellement `` ne vous embêtez pas à tester vos points de vue, il n'y a pas de logique et c'est trivial et sera couvert par un test d'intégration ''.

Je ne comprends pas comment cela est devenu la sagesse acceptée. Les tests d'intégration ont un objectif entièrement différent des tests unitaires. Si je casse quelque chose, je ne veux pas savoir une demi-heure plus tard quand mes tests d'intégration se cassent, je veux savoir immédiatement.

Exemple de scénario: disons que nous avons affaire à une application CRUD standard avec une entité client. Le client a un nom et une adresse. À chaque niveau de test, je veux vérifier que la logique de récupération du client obtient correctement le nom et l'adresse.

Pour tester unitaire le référentiel, j'écris un test d'intégration pour frapper la base de données. Pour tester les règles métier de façon unitaire, je moque le référentiel, alimente les données appropriées des règles métier et vérifie que mes résultats attendus sont renvoyés.

Ce que j'aimerais faire: Pour tester l'unité de l'interface utilisateur, je moque les règles métier, configure mon instance client attendue, rend la vue et vérifie que la vue contient les valeurs appropriées pour l'instance que j'ai spécifiée.

Ce que je suis bloqué: pour tester unitaire le référentiel, j'écris un test d'intégration, configure une connexion appropriée, crée les données requises dans la base de données, ouvre un navigateur, navigue vers le client et vérifie que la page résultante contient les informations appropriées valeurs pour l'instance que j'ai spécifiée.

Je me rends compte qu'il existe un chevauchement entre les deux scénarios discutés ci-dessus, mais la principale différence est le temps et les efforts requis pour configurer et exécuter les tests.

Si je (ou un autre développeur) supprime le champ d'adresse de la vue, je ne veux pas attendre que le test d'intégration le découvre. Je veux est découvert et signalé dans un test unitaire qui est effectué plusieurs fois par jour.

J'ai l'impression que je ne saisis tout simplement pas un concept clé. Quelqu'un peut-il expliquer pourquoi vouloir une rétroaction immédiate sur la validité d'une vue MVC est une mauvaise chose? (ou si ce n'est pas mauvais, alors ce n'est pas la façon attendue d'obtenir ces commentaires)


1
"To unit-test the repository, I write an integration test"Attends quoi? Ce n'est pas un test unitaire du référentiel. Vous automatisez le test pour cela, mais le code sous test inclut toujours le DAL et la base de données. Pour tester le référentiel unitaire, vous l'avez isolé comme vous l'avez fait pour vos règles métier.
StuperUser

Le test unitaire de la vue rendue comme prévu n'est qu'un test unitaire du fonctionnement de votre moteur de modèles. C'est comme tester unitaire votre C compilé contient certains morceaux de code machine, votre unité testant le compilateur pas votre code.
Raynos

2
@Raynos Respectueusement, je vais devoir être en désaccord. Si je (ou un autre développeur) connecte par erreur l'interface utilisateur pour rendre un attribut de données dans le champ d'interface utilisateur pour un autre (par exemple, "Prénom" dans le "Champ de nom", cela n'a rien à voir avec le moteur de modèle, ni est-ce un problème DAL ou BR .. c'est clairement un problème qui ne serait exposé que sur la vue.
Peter Bernier

1
@PeterBernier vous avez un bon point, mais j'ai du mal à définir la ligne entre "tester si le compilateur fonctionne" et "tester si mon code fonctionne". Sans oublier que les tests pour l'interface utilisateur sont étroitement couplés à l'interface utilisateur. Toute modification de l'interface utilisateur entraîne l'échec des tests. Vous ne pouvez pas vraiment refactoriser l'interface utilisateur sans provoquer l'échec d'un test.
Raynos

Réponses:


9

Les tests d'interface utilisateur simples sont assez faciles dans ASP.NET MVC. Essentiellement, tout ce que vous avez à faire est d'affirmer que le code HTML renvoyé contient les éléments dont vous avez besoin. Bien que cela garantisse que la page HTML est structurée comme vous l'attendez, elle ne teste pas complètement l'interface utilisateur.

Les tests d'interface utilisateur Web appropriés nécessitent un outil comme Selenium qui utilisera les navigateurs sur votre machine et garantira que JavaScript et HTML fonctionnent correctement dans tous les navigateurs. Selenium a un modèle client / serveur afin que vous puissiez avoir un ensemble de machines virtuelles avec des clients Unix, Mac et Windows et l'ensemble de navigateurs communs à ces environnements.

Maintenant, une application MVC (pattern, pas framework) bien conçue met la logique importante dans les modèles et les contrôleurs. En bref, la fonctionnalité de l'application est testée lorsque vous testez ces deux aspects. Les vues ont tendance à avoir uniquement une logique d'affichage et sont facilement vérifiées par inspection visuelle. En raison du traitement fin de la vue et de l'essentiel de l'application bien testée, beaucoup de gens ne pensent pas que la douleur de tester la couche de vue l'emporte sur les avantages qui en découlent.

Cela dit, MVC a de belles fonctionnalités pour vérifier le DOM retourné par la demande. Cela réduit considérablement la douleur lors du test de la couche de vue.


1
"Essentiellement, tout ce que vous avez à faire est d'affirmer que le code HTML renvoyé contient les éléments dont vous avez besoin." C'est exactement ce que j'essaie de faire et cela s'avère non trivial. Pouvez-vous indiquer un lien où cela fonctionnera avec une action de contrôleur spécifique au lieu de simplement rendre un contrôle? (J'ai travaillé sur quelques articles, mais RenderPartial n'accomplit pas ce que je veux faire sans frais généraux importants.)
Peter Bernier

Vous voudrez vérifier mvccontrib.codeplex.com (MVC Contrib). Cela fournit une aide qui n'était pas intégrée au langage principal et qui était recommandée dans le livre "Test-Drive ASP.NET MVC" (programmeurs pragmatiques). Je pense toujours que Selenium est mieux adapté aux tests View, cependant.
Berin Loritsch

TestHelper (MVC Contrib): mvccontrib.codeplex.com/…
Berin Loritsch

Le sélénium (dans mon cas, le sélénium RC) est ce que j'utiliserai pour mes tests d'intégration. Ce que je veux, c'est qu'un échec se produise avant ce point.
Peter Bernier

2
@Peter: Votre commentaire sur vos efforts étant "non triviaux" est exactement la raison pour laquelle les vues de test unitaire sont désapprouvées. Par conséquent, une stratégie typique consiste à rendre les vues aussi fines que possible (c'est-à-dire ne contenant aucune logique métier), de sorte que la plupart des tests unitaires puissent avoir lieu ailleurs (généralement dans le ViewModel). Les vues elles-mêmes peuvent être vérifiées par inspection visuelle ou avec un outil de test d'interface utilisateur comme Selenium.
Robert Harvey

7

Je ne dirais pas que c'est mal vu. Au contraire, ce sentiment est le résultat du fait que les vues MVC de test unitaire (au moins de la variété aspx) sont assez difficiles car les vues aspx dépendent trop des WebForms, qui sont eux-mêmes tout à fait non testables. Donc, l'argument veut que ce n'est pas vaut la peine, car les opinions ne sont généralement pas si compliquées.

Bien sûr, les vues peuvent devenir assez compliquées, c'est donc votre choix.


3
Les vues ASP.NET MVC ne sont pas liées aux formulaires Web, à ma connaissance. N'est-ce pas un des gros points pour ASP.NET MVC que ce ne sont pas des formulaires Web?
Adam Lear

Mon point de vue est qu'il faut plus d'efforts humains pour écrire les tests d'intégration pour couvrir l'interface utilisateur que pour écrire de vrais «tests unitaires» pour couvrir les vues. C'est pourquoi j'essaie de comprendre une partie de la résistance qui semble exister à l'égard de l'écriture de tests unitaires pour les vues.
Peter Bernier

Les vues @Anna Aspx sont construites au-dessus de WebForms. Ils dérivent de la System.Web.UI.WebControls.Pageclasse, utilisent des <asp:ContentPlaceholder>contrôles, etc. La façon dont MVC les exécute évite une grande partie du pipeline d'exécution de page généralement associé aux WebForms mais il utilise toujours beaucoup de trucs WebForms sous les couvertures.
marcind

Si vous utilisez un moteur de vue différent (tel qu'un rasoir), vous devriez pouvoir vous éloigner davantage du moteur Webforms.
The Muffin Man

6

Je ne suis pas sûr que ce soit mal vu. La testabilité est l'un des principaux avantages de l'utilisation d'ASP.NET MVC. Check-out le blog de Steve Sanderson pour plus d'informations à ce sujet.

Il a également écrit haut la main livre ASP.MVC (IMO) de loin. Non seulement il enseigne le MVC, mais il va au-delà pour enseigner les meilleures pratiques à ce sujet, y compris les pratiques de test.

Je pense que je dois clarifier un peu les vues des tests unitaires - vous pouvez créer des tests unitaires autour du résultat renvoyé par le contrôleur (ActionResult, etc.). Vous devrez toujours effectuer d'autres tests pour l'interface utilisateur et l'interaction UI réelles.


"Vous devrez toujours effectuer d'autres tests pour l'interface utilisateur et l'interaction UI réelles." C'est exactement mon point de la question .. pourquoi les tests d'interface utilisateur font soudainement partie des «autres tests» (c'est-à-dire les tests d'intégration). J'avais vu beaucoup de contenu de Steve Sanderson et c'est en quelque sorte ce qui m'a fait commencer dans cette voie, essayant essentiellement de reproduire ce qu'il fait avec son projet `` MvcFakes '' et rencontrant des problèmes avec son code en cours d'écriture pour les anciennes versions de MVC. .
Peter Bernier

1

Vous pouvez apprendre comment tester la vue renvoyée par une action de contrôleur, comment tester les données de vue renvoyées par une action de contrôleur et comment tester si une action de contrôleur vous redirige ou non vers une deuxième action de contrôleur en consultant l'URL suivante, décrire dans ce bref article sur le test des données de vue dans MVC .

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.