Comment implémenter TDD dans ASP.NET WebForms

Question

Je sais que la raison pour laquelle Microsoft est sorti avec ASP.NET MVC était de rendre plus simple de faire TDD (Test Driven Design) pour ASP.NET. Cependant, j'ai une assez grande application marron (existante) dans ASP.NET WebForms que j'adorerais implémenter certaines fonctionnalités de type TDD. Je suppose qu'il existe un moyen de le faire, mais quelles sont les options viables?

Answer 1

Microsoft a présenté ASP.NET MVC parce qu'il pensait pouvoir gagner de l'argent sur un marché inexploité - ceux qui estiment que les formulaires Web sont trop lourds et qui programment en utilisant un cadre plus léger. Cela inclut ceux qui sont habitués au paradigme MVC.

Il comprend également ceux qui ne pouvaient pas comprendre comment effectuer des tests unitaires dans des formulaires Web, et qui veulent utiliser des tests unitaires et TDD. La manière de le faire avec les formulaires Web, comme avec n'importe quoi d'autre, est de séparer tout sauf le code d'interface utilisateur en classes séparées dans une bibliothèque de classes. Utilisez TDD pour développer ces classes. Le prochain niveau de controverse est de savoir s'il est nécessaire d'utiliser TDD pour développer le reste du code: le balisage, le code côté client, les interactions avec l'utilisateur, etc. Ma réponse est que si vous avez le reste isolé et testé, que ça ne vaut pas la peine d'utiliser TDD pour cela.

Considérez: vos pages doivent avoir une apparence particulière. Allez-vous écrire un test unitaire qui échoue pour prouver que vous utilisez correctement CSS? Pour prouver que vous utilisez les styles CSS corrects? Je ne pense pas. Pour clarifier: Dans TDD, nous commençons par un test unitaire défaillant. Nous faisons ensuite les changements les plus simples possibles qui feront le test réussir. Imaginez l'utilisation de TDD pour une page Web.

Quels tests échouer allez-vous produire?

1. test cette page est bien formé HTML
2. test cette page contient le titre correct
3. test cette page comprend
   1. étiquette "Enter ID"
   2. Une zone de texte identifiant
   3. Une grille de données
   4. Un bouton "Go"
4. Vérifiez que la grille de données est vide après un test
5. Vérifiez que la grille se charge avec les données du client 1 lorsque "1" est entré dans la zone de texte et que "OK" est cliqué.

Et aucun des tests ci-dessus pour l'apparence de la page. Rien de tout cela ne teste le comportement côté client de tout JavaScript sur la page. Je pense que c'est stupide. Au lieu de cela, testez votre méthode DAL qui récupère les données en fonction de l'ID. Assurez-vous qu'il renvoie l'ID correct pour l'ID 1.Ensuite, combien de temps faudra-t-il pour tester manuellement la page pour vous assurer qu'elle semble correcte, vous pouvez entrer le "1" et cliquer sur "Go", et les données qui apparaissent dans la grille sont les données correctes pour le client 1?

Le développement piloté par les tests et les tests unitaires automatisés sont destinés à tester le comportement. L'interface utilisateur d'un formulaire Web est principalement déclarative. Il y a un grand "décalage d'impédance" ici.

Answer 2

Vous pouvez exécuter des tests basés sur HTTP pour tester la fonctionnalité de haut niveau. Le mieux serait d'encapsuler le code code-behind dans votre couche de gestion et de lancer des tests unitaires dessus.

Answer 3

Vous pouvez utiliser le cadre officiel UnitTest: http://msdn.microsoft.com/en-us/library/ms182526.aspx

Answer 4

tout d'abord, il est vraiment difficile de tester WebForms. Mais si vous présentez une logique aux contrôleurs/présentateurs comme le modèle MVC/MVP, vous pouvez au moins tester les présentateurs.

pseudo-code

Default.aspx

public void Page_Init(object sender, EventArgs e) { 
_presenter = new DefaultPresenter(IDependencyOne, IDependencyTwo etc) //Init new presenter, either from IoC container of choose or "new-it-up" 
} 

public void Save() { 
_presenter.Save(txtValue.Text) 
} 

Que vous pouvez facilement tester le présentateur dans l'isolement au moins =)