Lorsque vous testez votre interface utilisateur basée sur MVC, quelle est la part de la configuration de test que vous rendez commune ?

Question

J'essaie de tester une interface utilisateur simple basée sur WebForms (asp.net), et de suivre le modèle MVP pour permettre à mon interface d'être plus testable.

En suivant la méthodologie TDD pour les algorithmes backend, je constate que certains remaniements de tests unitaires se produisent dans l'esprit du principe DRY (Don't Repeat Yourself). Lorsque j'essaie d'appliquer ce principe à l'interface utilisateur en utilisant Rhino Mocks pour vérifier mes interactions, je vois de nombreux points communs dans les tests du contrôleur lors de la mise en place des attentes de la vue ou du modèle.

Ma question est la suivante : jusqu'où poussez-vous généralement ce remaniement, si tant est que vous le fassiez ? Je suis curieux de voir comment les autres TDDer testent leurs interfaces utilisateur basées sur MVC/MVP.

Answer 1

Je ne remanierais pas les tests comme du code standard. Les tests commencent à devenir plus obscurs au fur et à mesure que vous refactorisez les choses en classes de base communes, en méthodes d'aide, etc. Les tests devraient être suffisamment clairs par eux-mêmes.

La sécheresse n'est pas une préoccupation du test.

Cela dit, il y a beaucoup de choses de plomberie qui sont couramment faites, et celles-ci devraient être abstraites.

Answer 2

J'utilise MVP, et sur mes tests j'essaie d'appliquer la plupart du remaniement que je ferais dans du code standard. Normalement, cela ne fonctionne pas aussi bien sur les tests, en raison des légères variations nécessaires pour tester différents scénarios, mais dans certaines parties, il peut y avoir des points communs, et lorsque c'est possible, je les consolide. Cela facilite les changements nécessaires plus tard, au fur et à mesure que le projet évolue ; tout comme dans votre code standard, il est plus facile de modifier un endroit plutôt que 20.

Answer 3

Je préfère traiter les tests unitaires comme de purs programmes fonctionnels, pour éviter d'avoir à les tester. Si une opération est assez commune entre les tests, alors je l'évaluerais pour la base de code standard, mais même dans ce cas, j'éviterais de refactorer les tests, car j'ai tendance à en avoir beaucoup, surtout pour les BL pilotés par interface.

Answer 4

J'utilise Selenium pour les tests fonctionnels et j'utilise JUnit pour tester mes contrôleurs.

Je vais simuler les services ou les ressources utilisés par le contrôleur et tester pour voir vers quel URI le contrôleur redirige, etc...

La seule chose que je ne teste pas vraiment à ce stade, ce sont les vues. Mais j'ai employé des tests fonctionnels pour compenser.