Comment puis-je écrire un test unitaire pour une classe de contrôleurs qui utilise winforms pour les vues?

Question

Quelqu'un a-t-il déjà réussi à unifier les méthodes de test qui sont nécessairement couplées à la classe System.Windows.Forms.Form?

J'ai récemment travaillé sur une application winforms C #, en essayant de la construire avec une structure MVC. C’est déjà assez difficile, étant donné que le cadre n’est pas vraiment construit dans cet esprit.

Cependant, la situation devient encore plus difficile lorsque vous intégrez des tests unitaires. Je me suis assuré que mes contrôleurs ne sont pas couplés à des classes de vues concrètes, de sorte que je puisse utiliser un stub / mock pour les tests unitaires. Toutefois, il est inévitable de référencer la classe de formulaire quelque part , et ces méthodes doivent être testées.

J'utilise Moq car il comporte de jolies fonctionnalités de sécurité du type, et permet de se moquer des types concrets. Mais malheureusement, cela ne me permet pas de "m'attendre". des appels à des méthodes ou des propriétés sur un type concret qui ne sont ni virtuelles ni abstraites. Et comme la classe Form n'a pas été construite avec des sous-classes, c'est un gros problème. Je dois pouvoir me moquer de la classe Form pour empêcher la création de véritables fenêtres en "attendant". ShowDialog, par exemple.

Il m'est donc impossible d'exécuter des tests unitaires faisant beaucoup d'interaction avec les sous-classes de Form, qui sont mes vues.

Y a-t-il quelqu'un qui a testé ce type de code avec succès? Comment l'avez-vous fait?

Est-ce quelque chose que d'autres frameworks moqueurs peuvent contourner? Les méthodes basées sur des chaînes de caractères utilisées par d'autres frameworks moqueurs seraient-elles soumises aux mêmes contraintes? Puis-je écrire mes propres classes fictives de longue main explicites, ou le manque de membres virtuels m'empêchera-t-il de supprimer également le comportement de la fenêtre?

Ou y a-t-il un moyen auquel je n'ai pas pensé de structurer mes classes de sorte que le code couplé à des formulaires aboutisse à des méthodes et à des classes d'une complexité triviale, de sorte que je puisse m'en sortir sans les tester explicitement, sans ma conscience me battre pour cela?

Answer 1

La meilleure méthode dont j'ai entendu parler / utilisée pour les tests unitaires avec des éléments d'interface graphique est le Dialogue humble modèle / méthode. Essentiellement, les formulaires ne sont que l'interface et tout le travail réel est effectué dans d'autres classes. Vous testez les classes qui fournissent la fonctionnalité, puis vous liez simplement les événements de votre interface graphique aux méthodes appropriées de ces classes.

Answer 2

Je pense actuellement que je devrais peut-être utiliser la composition plutôt que l'héritage avec la classe Form pour découpler les contrôleurs.

Cela a pour inconvénient que chaque fois que je dois utiliser un membre de la classe Form que je n'ai pas planifié, je dois l'ajouter explicitement à mon interface d'affichage.