2010-12-02 5 views
5

Mon application a déjà test unitaire pour la couche de domaine je voudrais savoir quels sont les avantages/inconvénients du contrôleur de tests unitairesAvantages MVC des contrôleurs d'essai Unité

et quels cas essai doit-on écrire lors du test des contrôleurs.

Merci

Répondre

5

Cela dépend.

La validation, la redirection, les messages temporaires, etc. peuvent se produire dans les contrôleurs. Vous pourriez argumenter que ces opérations devraient être testées comme vous le feriez avec vos modèles.

D'un autre côté, vous devriez viser l'état d'esprit 'Fat Model, Skinny Controller'. J'ai tendance à m'assurer que mes contrôleurs sont aussi stupides que possible. Mettez quelques tests de bout en bout sur les caractéristiques qui vous intéressent (sélénium, concombre, etc ...) et celles-ci feront en sorte que vos contrôleurs sont corrects. Supposons que nous développions une fonctionnalité pour répertorier certains éléments. Si le test de bout en bout de cette fonctionnalité est bon, le contrôleur est correct. Si cela casse, vous saurez que vous avez introduit une régression. En combinaison avec cela, j'ai seulement des tests qui vérifient que les vues correctes sont rendues et la réponse correcte se produit - redirection, json etc ... N'importe quel more testing on your controller et vous avez la logique au mauvais endroit.

Dans ASP.NET MVC2 par Steve Sanderson il fait quelques excellents points au sujet du raisonnement ci-dessus. Je le recommande complètement. Le fait de ne pas avoir ces tests de contrôleur simples est que je pourrais facilement ouvrir votre base de code, faire un simplement changer et casser votre application. Tant que les vues/réponses correctes se produisent, l'application reste fonctionnellement intacte.

Je devrais ajouter que tester un service est invoqué dans un contrôleur avec les paramètres corrects est si trivial, et rapide à faire, vous pouvez aussi bien le faire si vous testez vos contrôleurs indirectement. J'ai tendance à favoriser cette approche dans son ensemble. Donc, la réponse complète à votre question est oui, testez vos contrôleurs;)

0

pensée A 'Pro':

Dans le cas où vous transmettre des données quantifiables ou des paramètres du contrôleur à une vue.

Dans certains cas, bien que je pense limité ou rare, tester la logique interne dans le contrôleur qui n'est pas couvert par vos tests de code de support. Bien qu'on puisse soutenir que ces morceaux de code devraient être déplacés.

Pensée A « Con »:

Si vos tests pour les contrôleurs ne sont pas ajouter de couverture de code supplémentaire ou dupliquez la couverture des tests, il serait tout simplement les frais généraux et ajouter le temps de développement pour aucun avantage.

0

Même si vous devez toujours vous efforcer de garder la logique métier hors de vos contrôleurs, il existe souvent des cas où la construction du modèle de vue peut être si complexe qu'il vaut la peine de la tester. Par exemple lors de l'affichage d'une vue avec plusieurs menus de sélection qui sont remplis par des requêtes linq complexes sur votre base de données via des modèles de vue personnalisés. Ce genre de logique n'est pas la logique métier, donc le mettre dans la couche métier ne semble pas correct. D'un autre côté, il doit être testé.

Editer: Pour clarifier, je ne veux pas dire mettre des requêtes select dans votre vue. Cela validerait le modèle MVC. Ce que je veux dire, c'est un contrôleur qui exécute de telles requêtes et construit des modèles de vue personnalisés complexes avec les résultats pour l'affichage de la vue.

+0

La vue ne devrait pas avoir connaissance de vos requêtes - les résultats sont positifs. Les vues ne doivent pas être liées à la base de données. – Finglas

+0

+1 pour le commentaire honnête sur le fait que la logique pour sélectionner la vue correcte ou viewmodel peut être très complexe sur certains cas et il vaut la peine de tester. –

+0

@Finglas: Il semble y avoir un malentendu: Mon point de vue n'a aucune connaissance de la requête. C'est exactement pourquoi le contrôleur est en train de construire un viewmodel personnalisé avec le résultat de la requête. –

1

Certaines choses qui peuvent être des tests valeur dans les actions du contrôleur:

  1. logique de l'interface utilisateur qui est renvoyée dans le modèle de vue (par exemple, la visibilité, les valeurs de la liste déroulante, etc.)
  2. Redirects (par exemple les utilisateurs connectés aller à la page d'accueil redirigés vers une autre page à la place)
  3. validation/alertes
0

L'un des problèmes que j'ai rencontré lors du test des contrôleurs est que, dans certains cas, vous devez émuler la chaîne d'exécution qu'ASP.NET MVC suit Testez votre contrôleur. Par exemple, si vous avez du code dans votre méthode OnExecuting, vous devez trouver un moyen de déclencher cette méthode lorsque vous exécutez la méthode d'action réelle dans votre contrôleur pendant votre test unitaire.

Questions connexes