Comment tester une interface utilisateur WPF ?

Question

Utilisation des formulaires win avec un MVC / MVP architecture, je devrais normalement utiliser une classe pour envelopper une vue afin de tester l'interface utilisateur tout en utilisant des objets fantaisie pour le modèle et le contrôleur/présentateur. La classe enveloppante fait de la plupart des éléments de l'interface utilisateur une propriété observable par le programme d'exécution des tests grâce à des propriétés et des événements.

S'agit-il d'une approche viable pour tester une application WPF ? Existe-t-il une meilleure méthode ? Y a-t-il des problèmes auxquels il faut faire attention ?

Answer 1

En ce qui concerne le test en lui-même, il est probablement préférable d'utiliser la fonction Automatisation de l'interface utilisateur cadre. Si vous voulez utiliser le framework de manière plus fluide et indépendante de wpf/winforms/win32/swt, vous pouvez télécharger Blanc de Codeplex (à condition que vous soyez en mesure d'utiliser du code source ouvert dans votre environnement).

Pour ce qui est des problèmes, si vous essayez de tester vos vues, vous rencontrerez probablement des problèmes de threading. Par exemple, si vous utilisez NUnit, le testrunner par défaut fonctionnera en MTA (Multi-Threaded Appartment), alors que WPF doit fonctionner en STA (Single-threaded Appartment). Mike Two propose une mise en route très facile pour tester WPF à l'unité, mais sans prendre en compte la question du threading. Josh Smith a quelques idées sur la question du threading dans le document suivant ce poste et il souligne également cet article par Chris Hedgate. Chris utilise une version modifiée de la méthode de Peter Provost. CrossThreadTestRunner pour emballer les questions MTA/STA d'une manière un peu plus amicale.

Answer 2

@Matt David,

Veuillez lire la documentation et jeter un coup d'œil aux exemples de code pour Microsoft. CompositeWPF (alias Prism). Il s'agit d'un projet créé spécifiquement pour enseigner comment traiter l'architecture MVP/MVC de manière pilotée par les tests. Leur application type contient des tests unitaires pour les présentateurs \controllers et des tests d'acceptation très cool pour l'interface utilisateur (ils utilisent Cadre blanc pour simuler les actions de l'utilisateur)

Answer 3

Manuellement. Je ne suis pas un grand fan de l'automatisation Tests de l'interface utilisateur si c'est ce que vous voulez dire. Je ne suis pas sûr des directives de WPF (je dois lire les liens d'aku)... parce qu'elles sont encore en train de se solidifier pour ainsi dire... WPF ne s'est pas stabilisé du point de vue de "ce qui est la bonne façon". A moins que vous n'utilisiez l'un de ces cadres évolutifs... Je serais conservateur en ce qui concerne l'effort.

• Testez (de préférence de manière automatisée et TDD) la logique/les présentateurs/les contrôleurs de manière impitoyable. Je ne prône pas le laisser-aller ou la léthargie. .
• Gardez la peau de l'interface utilisateur mince et obtenez des testeurs méchants. de se lancer dans des tests exploratoires (manuels) - rien ne vaut un "testeur de l'enfer" lorsqu'il s'agit d'interfaces utilisateur. Le rapport effort/gain de l'automatisation de ce type de test est énorme, ne permet pas de tout attraper et n'a pas de sens... sauf pour apaiser les hauts responsables "Regardez Mgr ! Pas de mains ! Des interfaces utilisateur auto-testées !

PS : vous voudrez peut-être regarder ceci (le Google Talk de Mary Poppendieck sur le Lean) surtout la partie sur ce qu'il faut automatiser dans les tests

Answer 4

Prism (WPF composite) est construit principalement en gardant la "testabilité" à l'esprit. Allez-y, si vous pensez qu'il convient à votre type de développement.

Voici également le l'épisode des dotnetrocks que vous pouvez écouter, si vous avez besoin de plus d'informations sur Prism en audio.

Answer 5

Pour les bases, vous pouvez également consulter quelques courtes vidéos sur channel9. aquí y aquí .