Question

Nous travaillons sur un projet ici dans Visual Studio 2008. Nous utilisons la suite de tests intégrée fournie avec celui-ci (l'espace de noms Microsoft.VisualStudio.TestTools.UnitTesting). À notre grand regret, il s’avère que beaucoup de complexité (et donc d’erreurs) ont été codées dans notre couche d’UI. Alors que nos tests unitaires couvrent bien notre couche métier, notre couche d'interface utilisateur est une source constante d'irritation. Nous aimerions idéalement effectuer des tests unitaires également. Est-ce que quelqu'un connaît un bon " Microsoft-compatible " façon de faire cela en studio visuel? Cela introduira-t-il une sorte de conflit pour "mélanger" des infrastructures de tests unitaires telles que nUnitForms avec les outils Microsoft? Y a-t-il des pièges à ours évidents dont je devrais être au courant avec les formulaires de test unitaire?

Était-ce utile?

La solution

Il vous faudrait refacturer l'interface utilisateur afin qu'elle ne nécessite aucun test unitaire. L'interface utilisateur doit contenir un minimum ou pas de logique métier. Il existe de nombreux modèles qui traitent de cette question. Martin Fowler a un très bon article qui explique beaucoup de choses sur ces modèles: http://martinfowler.com/eaaDev/ uiArchs.html

Il y a un petit chapitre dans le livre de Refactoring de Martin Fowler qui parle de refactorisation de l’UI non testable. Vous pouvez également lire Travailler efficacement avec du code existant.

Remarque: il existe un outil qui pourrait être utilisé pour automatiser le test de l'interface utilisateur. SilkTest me vient à l'esprit. Mais je ne les utiliserais pas si possible.

Autres conseils

Cela convient parfaitement pour les tests unitaires d'application classiques ... mais si vous créez des contrôles utilisateur qui nécessitent des tests unitaires pour les comportements et les états de contrôle, vous avez également besoin d'un framework de test unitaire. NUnitForms pourrait être la solution pour vous - personnellement, je dois le vérifier moi-même.

J'utilise l'architecture de la vue passive décrite ici http://martinfowler.com/eaaDev/PassiveScreen. html

En gros, déplacez tout votre code des formulaires dans une classe distincte appelée xxxUI. Le formulaire implémente ensuite une interface IxxxUI et expose tout ce dont la classe xxxUI a besoin. Vous pouvez probablement simplifier les choses et regrouper plusieurs méthodes en une seule méthode.

Le flux passe ensuite. L'UTILISATEUR clique sur un bouton. Le bouton appelle une méthode sur la classe d'interface utilisateur correspondante. Passer tous les paramètres nécessaires. La méthode UI Class modifie le modèle. Ensuite, utiliser l'interface met à jour l'interface utilisateur.

Pour les tests unitaires, vous avez demandé à des classes test ou factices d'implémenter les interfaces et de s'enregistrer auprès des classes d'interface utilisateur. Vous pouvez demander à ces classes de test de déclencher tout type d’entrée et de réagir en conséquence. En général, j'ai des listes de séquences qui agissent dans un ordre précis. (Appuyez sur A, cliquez dessus, faites défiler, puis tapez B, etc.).

Il est assez facile de tester les Winforms avec ApprovalTests (www.approvaltests.com ou tests d’approbation de nuget) et ils sont compatibles avec MsTest et Nunit.

Vous trouverez ici une vidéo expliquant comment procéder: https://www.youtube.com/ regarder? v = hKeKBjoSfJ8

Mais le processus est simple. 1) créez le formulaire que vous souhaitez tester dans l’état que vous souhaitez vérifier. 2) appelez WinFormApprovals.Verify (formulaire)

ApprovalTests utilise le paradigme du maître d’or pour capturer le résultat. si vous l'aimez, renommez simplement le fichier en .approved et le test réussira.

L'avantage de cette refonte du code existant est que vous n'avez même pas à vous soucier du résultat, car vous ne craignez que de ne pas le changer.

Découvrez le WIP de la page de présentation des modèles de présentation de Jeremy D. Miller pour une refonte de l'inspiration: )

Miller est en train d'écrire un livre et il semble que ce sera un must pour ce genre de chose.

J'ai utilisé NUnitForms pour tester mes propres contrôles d'interface utilisateur avec de bons résultats! Je suis d’accord avec les autres sur la refactorisation si vous utilisez des contrôles d’UI standard (ou bien testés).

Si l'accent est mis sur le test des contrôles réels, j'utiliserais NUnitForms car il peut être étendu pour prendre en charge vos nouveaux contrôles. Quoi qu'il en soit, si vous ne voulez pas impliquer de test manuel, vous aurez besoin d'une librairie qui peut faire "basé sur l'image". analyse du résultat final affiché.

J'ai essayé TestComplete pour cela, mais j’ai pensé que c’était un peu trop cher, car je pouvais coder une bibliothèque similaire pour seulement la comparaison d’images en c #. Mon plan serait donc de tester les contrôles séparément, puis de refacturer l'interface utilisateur comme indiqué par les autres.

Vous devez utiliser l'interface utilisateur codée Microsoft pour tester la couche d'interface utilisateur. Cela implique d'écrire (ou d'enregistrer) des tests imitant les actions qu'un utilisateur effectuerait et d'écrire des instructions d'assertion pour s'assurer que la sortie correcte est obtenue.

Bien sûr, il ne s'agit pas de tests unitaires discutables, car il est difficile de créer des actions initiales qui testent une seule unité de travail et ne remplacent pas les autres tests unitaires. Je conviens également que la logique métier initiale doit être aussi fine que possible. Toutefois, cela permettra de combler les lacunes que vos tests unitaires ne couvrent pas. J'espère que seules vos petites unités de travail ne seront pas couvertes par vos tests unitaires, de sorte que les tests d'interface utilisateur codés captureront les unités non testées restantes.

L'interface utilisateur codée est intégrée aux dernières versions de Visual Studio Premium. Je suggère que vous n'utilisiez pas simplement la fonctionnalité d'enregistrement, mais que vous appreniez à écrire les tests vous-même, car cela vous donne une plus grande flexibilité.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top