Meilleure pratique pour intégrer TDD au développement d'applications Web?

Question

Les tests unitaires et les applications Web ASP.NET constituent un point ambigu dans mon groupe. Plus souvent qu'autrement, les bonnes pratiques de test tombent à travers les fissures et les applications web finissent par aller vivre pendant plusieurs années sans tests.

La cause de ce point de douleur tourne généralement autour des tracas de l'écriture UI automation mid-development. Comment votre organisation ou vous-même intégrez-vous les meilleures pratiques de TDD dans le développement d'applications Web?

Answer 1

Les tests unitaires seront réalisables si vous séparer vos couches de manière appropriée . Comme Rob Cooper l'a laissé entendre, ne met pas de logique dans votre WebForm autre que logique pour gérer votre présentation. Toutes les autres couches de logique et de persistance doivent être conservées dans des classes séparées, puis vous pouvez les tester individuellement.

Pour tester l'interface utilisateur, certaines personnes aiment selenium. D'autres se plaignent que c'est une douleur à mettre en place.

Answer 2

Je superpose l'application et au moins le test unitaire du présentateur/contrôleur (selon votre préférence, mvc/mvp) à la couche de données. De cette façon, j'ai une bonne couverture de test sur la plupart du code qui est écrit. J'ai examiné FitNesse, Watin et Selenium en tant qu'options pour automatiser le test de l'interface utilisateur, mais je n'ai pas encore commencé à les utiliser sur des projets, donc nous nous en tenons aux tests humains. FitNesse était celui sur lequel je me penchais mais je ne pouvais pas introduire cela aussi bien que l'introduction de TDD (cela me rend-il mauvais? J'espère pas!).

Answer 3

Ceci est une bonne question, que je vais abonne aussi :)

Je suis encore relativement nouveau pour dev web, et je suis trop regardant beaucoup de code qui est en grande partie non testé. Pour moi, je garde l'interface utilisateur aussi légère que possible (normalement seulement quelques lignes de code) et de tester la merde sur tout le reste. Au moins, je peux alors avoir une certaine confiance que tout ce qui le rend à l'interface utilisateur est aussi correct que possible.

Est-ce parfait? Peut-être pas, mais au moins il est encore très hautement automatisé et le code de base (où la plupart de la «magie» se produit) a toujours une bonne couverture ..

Answer 4

Une pratique courante consiste à déplacer tout le code que vous pouvez sortir du codebehind et dans un objet que vous pouvez tester de manière isolée. Ce code suivra généralement les modèles de conception MVP ou MVC. Si vous effectuez une recherche sur "Rhino Igloo", vous trouverez probablement le lien vers son dépôt Subversion. Ce code mérite d'être étudié, car il démontre l'une des meilleures implémentations MVP sur les formulaires Web que j'ai vu.

Votre codebehind sera, en suivant ce schéma, faire deux choses:

1. Transit toutes les actions de l'utilisateur au présentateur.
2. Données de rendu fournies par le présentateur.

L'unité testant le présentateur doit être triviale.

Mise à jour: Rhino Igloo se trouve ici: https://svn.sourceforge.net/svnroot/rhino-tools/trunk/rhino-igloo/

Answer 5

Il y a eu essais sur l'obtention de l'automatisation de l'interface utilisateur gratuit de Microsoft (inclus dans le .NET Framework 3.0) pour fonctionner avec des applications Web (ASP.NET) de. Une entreprise allemande appelée Artiso a écrit une entrée de blog expliquant comment y parvenir (link). Cependant, leur blogpost relie également un webdiffusion MSDN qui explique le Framework UI Automation avec des winforms et après avoir jeté un coup d'oeil à cela, j'ai remarqué que vous avez besoin de l'AutomationId pour obtenir une référence aux contrôles de respect. Toutefois, dans les applications Web, les contrôles n'ont pas d'AutomationId.

J'ai demandé à Thomas Schissler (Artiso) à ce sujet et il a expliqué que c'était un inconvénient majeur sur InternetExplorer. Il a référencé une ancienne technologie de Microsoft (MSAA) et espérait lui-même que IE8 le ferait mieux. Cependant, je donnais aussi un essai à Watin et cela semble fonctionner plutôt bien. J'ai même aimé Wax, qui permet d'implémenter des tests simples via des feuilles de calcul Microsoft Excel.

Answer 6

Ivonna peut tester votre point de vue. Je recommande toujours de déplacer la majeure partie du code vers d'autres parties. Cependant, un code juste appartient, comme des références aux contrôles ou aux gestionnaires d'événements de contrôle.

Answer 7

J'éviterais généralement les tests qui impliquent l'utilisation d'éléments d'interface utilisateur. Je privilégie les tests d'intégration, qui testent tout de votre couche de base de données à la couche de vue (mais pas la mise en page réelle). Essayez de démarrer une suite de tests avant en écrivant une ligne de code dans un nouveau projet, car il est plus difficile d'écrire des tests plus tard. Choisissez avec soin ce que vous testez. N'écrivez pas des tests pour tout. Parfois, c'est une tâche ennuyeuse, alors ne le compliquez pas. Si vous écrivez trop de tests, vous risquez d'abandonner cette tâche sous le poids d'une maintenance fastidieuse. Essayez de regrouper autant de fonctionnalités que possible en un seul test. De cette façon, si quelque chose ne va pas, les erreurs se propageront de toute façon. Par exemple, si vous avez une classe génératrice de digestes, testez la sortie réelle, pas toutes les fonctions auxiliaires.

Ne vous faites pas confiance. Supposons que vous fassiez toujours des erreurs et que vous écrivez des tests pour vous faciliter la vie, pas plus dur.

Si vous ne vous sentez pas bien dans les tests d'écriture, vous faites probablement mal;)

bien