Test d'une application WPF lourde de Gui

Question

Nous (mes collègues) ont un malpropre âgés de 12 ans.o. mature application qui est basé sur l'interface, et le plan actuel est d'ajouter de nouvelles boîtes de dialogue et autres IHM en WPF, ainsi que de remplacer les plus anciens les boîtes de dialogue dans WPF ainsi. Dans le même temps, nous voulons être en mesure de tester ce Monstre - GUI d'automatisation dans un maintenable façon. Quelques défis à relever:

1. La demande est énorme.
2. Elle ne cesse de nouveaux gains de fonctionnalités.
3. Il est en cours de modifications (corrections de bogues, les correctifs).
4. Il a une fin, et d'une couche dans l'entre-deux. L'état de l'il peut devenir hors de contrôle si vous le battre à mort.

Ce que nous voulons, c'est:

• Certains outil qui permet d'automatiser les tests de WPF.
• auto-découverte de ce que les entrées et les sorties de la boîte de dialogue sont. Un vieux test doit encore fonctionner si vous ajoutez une étiquette qui ne fait rien. Il doit échouer, cependant, si vous supprimez un nécessaire de champ de texte. Il serait très bien si la suite de test est facile à entretenir, si il a couru et n'a pas rompu la plupart du temps.
• Chaque nouvelle boîte de dialogue devrait être créé avec la testabilité à l'esprit.

À ce stade, je ne sais pas exactement ce que je veux, donc je suis ce marquage comme un wiki de la communauté. Si le fait de tester un énorme basé sur l'interface de l'app sonne la cloche (même si ce n'est dans WPF), alors s'il vous plaît de partager vos bon, mauvais et laid expériences ici.

Answer 1

OK, votre application sons grand! Je peux partager mes expériences autour d'une application, nous avons conçu récemment; il a une interface graphique parler des services web à un serveur qui à son tour contacté plusieurs bases de données et d'autres services web. Le client de base est d'environ 15 000 utilisateurs... de toute façon - c'est beaucoup de travail, peu importe la façon dont vous vous approchez d'elle; l'avantage est qu'il vous aidera à ne pas mâcher vos ongles à chaque fois que vous effectuez une mise à jour!

MVVM

En général, je recommande aussi la pattern MVVM et faire autant de tests que possible, sans interface graphique. GUI test est acharné! J'aime Josh Smith article sur MSDN: "des Applications WPF Avec Le Modèle model-View-ViewModel Modèle de Conception" (http://msdn.microsoft.com/en-us/magazine/dd419663.aspx)

Test De Script

Le truc avec cette application a été que nous avons eu beaucoup de test, les tripes sont constamment en mouvement et il y avait (étrangement) pas assez de gens pour obtenir les tests travail effectué pour chaque itération.

Ma solution a été à venir avec un outil de test qui a mobilisé les bibliothèques existantes. Nous avons eu un simple moteur de script que de lire un fichier et exécuté les commandes. En effet, nous avons développé un DSL (http://en.wikipedia.org/wiki/Domain-specific_language) pour tester notre application spécifique. Le DSL inclus quelques commandes simples pour signaler que "fenêtre", c'était des essais, des "setup" signaux et puis une série de commandes, suivi par des assertions. Ça ressemblait à quelque chose comme ceci:

Test NewXyzItem
Le Programme D'Installation Clear_items

Appuyez Sur Some_button
Enter_text_into Nom De Bobby Joe
(...)
Appuyez Sur Enregistrer

Assert_db_has_itemX SomeKey

Le format de chaque ligne est

"command" "argument" [data]

Les scripts d'aller dans des groupes de répertoires et le "testeur" de charges, les analyse et les exécute. La création de journaux et de rapports comme vous allez le est utile, je l'ai ajouté au crochet pour faire des captures d'écran, etc, qui est venu dans maniable. Si vous êtes intéressé à mettre en place quelque chose de likke, et d'une main, laissez-moi savoir.

La chose à portée de main, c'est que nous pourrions faire de couverture des modifications à la stratégie de test.

L'écriture de scripts devient assez simple qui est important parce que vous vous retrouvez avec beaucoup, beaucoup de scripts. Les contrôles sont découverts par nom si vous suivez une convention (par exemple, "Nom" peut être "NameTextBox" dans le code, ou sur "Enregistrer" pourrait être "SaveButton").

Vous pouvez réellement harnais NUnit etc à votre test runner trop.

REMARQUE - il suffit d'exécuter les tests de manière interactive, l'obtention de GUI test fonctionne avec CI est difficile et problématique...

Données et Tests

Une chose importante ici est que la gestion des données a été une énorme partie de l'épreuve problème et ne peut pas être négligé. Notre "frais de déploiement" a également été très long, mais certaines parties ont été externe et nous n'avons eu aucun contrôle sur la fraîcheur des données. La façon dont nous avons géré le service de nettoyage était de fournir des crochets à travers le script qui nous a permis de retirer facilement les objets avant de les tests. Pas optimal, mais il est rarement un problème.

Les bibliothèques

La bibliothèque que vous pouvez trouver le plus utile dans les "Blancs" (http://white.codeplex.com/) Il peut tester les applications windows en général – je.e WPF et WinForms. Essentiellement, en fin de codage des choses comme ceci:

Button button = window.Get<Button>("SaveButton");
button.Click();

Si votre application fait les appels asynchrones, vous aurez besoin de venir avec une stratégie pour le lanceur de test afin de savoir quand l'appel asynchrone est terminée, peut-être bien que la barre d'état ou de quelque chose. Ça dépend comment vous crochet dans...

Encore une fois, beaucoup de travail, mais ça en vaut la peine.

PK :-)

Answer 2

L'une des principales forces de WPF est en fait la capacité de ne PAS avoir besoin de l'INTERFACE utilisateur d'essais spécifiques, à mon avis. À l'aide d'un M-V-VM approche vous permettra de prendre la logique de l'INTERFACE utilisateur/sale-GUI-zone. Avoir une unité vérifiable ViewModel (surtout si vous êtes de l'écriture de nouvelles boîtes de dialogue!) permet d'écrire des tests unitaires qui émulent le clic de votre interface graphique.

J'aimerais vraiment revoir ce que vous voulez accomplir en se déplaçant à WPF et ce que vous voulez atteindre avec un certain type de tests automatisés de WPF GUI. Une fois cela établi, regarder dans la transition de la WinForms à WPF, si il s'adapte toujours à vos besoins.

Answer 3

Comme Jimmy Lyke dit, la plupart de vos tests devraient être centrés sur le ViewModel. Cela consiste à écrire des tests unitaires pour le ViewModel - fondamentalement, l'envoi des commandes et la définition et l'obtention de propriétés.

Une fois que c'est fait, 95% de votre test est hors de la voie. Si vous voulez prendre une étape supplémentaire et de test de la vue au-delà du manuel "soluces" les tests que vous feriez de toute façon, il y a un certain nombre de simple "vérifications", vous pouvez facilement automatiser pour vous assurer de ne pas accidentellement supprimer une importante zone de texte ou de rendre un indicateur visuel invisible.

Chacune des techniques ci-après peuvent être automatisées à l'aide d'un simple code d'automation utilise un "fusil de chasse" approche en aveugle de l'exécution de l'arborescence visuelle et en supposant que rien au sujet de la réelle structure d'INTERFACE utilisateur.

• Pour vérifier que tout le ViewModel de données est lié, trouvez tous les Visuels et Freezables (à l'aide de l'arborescence visuelle) et vérifier chaque propriété liée pour son BindingExpression du chemin de liaison.

• Pour vérifier que tout le ViewModel de données est affiché en quelque sorte, de faire varier le ViewModel de données à l'aide d'un script et après chaque modification utilise RenderTargetBitmap à la capture de l'INTERFACE utilisateur et de le comparer avec les données avant de les modifier assurez-vous que l'INTERFACE a changé.

• Pour vérifier que les valeurs de propriété sont en train d'être mis à jour correctement, trouvez tous les Visuels et Freezables, et scanne et enregistre toutes les propriétés liées sur eux, puis faire le ViewModel changement, rescan, et searche pour les changements attendus à la propriété d'un type donné. (Pour vérifier que vous pouvez ensuite utiliser l'image bitmap technique de comparaison sur le Visuel particulier affectée.)

• Pour vérifier que toutes les commandes sont accessibles, ensemble connu ViewModel état puis le feu chaque commande lié à un bouton qui est visible pour voir si l'un d'eux déclencher la ICommand ou autrement mettre à jour ViewModel de l'état.

• Pour vérifier qu'un ViewModel de la propriété est en fait modifiable par l'utilisateur, de modifier le contenu ou la sélection de chaque visibles TextBox, ComboBox, ListBox pour voir si l'un d'entre eux touchent la propriété.

• Avoir l'occasion de vérifier tout changement qui affecte l'INTERFACE utilisateur, de maintenir une base de données contenant des instantanés bitmap de chacun des points de vue dans différents ViewModel unis dans un ensemble de différentes tailles de fenêtre. Quand une nouvelle version de l'application est de créer, d'exécuter le même système de snapshot et de les comparer avec les précédentes images. Si quelque chose a changé, de générer une tâche manuelle pour le personnel de l'AQ de comparer visuellement l'ancien et le nouveau bitmaps pour voir si quelque chose d'important a changé.

D'autres automatisation de test est possible, sur la vue, mais le ci-dessus vous donnera un point de départ.

De nouveau, je dois souligner qu'il est préférable de se concentrer sur le fait de bien tester le ViewModel. Des Bugs dans l'affichage lui-même sont assez rares, généralement détecté rapidement, et généralement simple à résoudre. Mais une fois ViewModel test est complet, il est logique de faire une certaine automatisation de la vue des tests.

Answer 4

Vous avez une très grande application. J'imagine qu'il y a beaucoup de logique enveloppé avec la couche de présentation et vous ne serez jamais donné le temps de revoir la bête pour séparer le point de vue du reste de la logique.

Vous n'avez pas beaucoup de choix ici, mais:

1. Refactoriser le code comme vous allez le long. Cela peut être un peu de méthode d'extractions de sorte que vous pouvez unité de test ou de passer à un modèle adéquat.
2. Utilisez l'une ou plusieurs des options de Windows GUI outils de test. Remarque, si vous prévoyez beaucoup de mise en page et/ou le contrôle des changements, pour la retarder aussi longtemps que possible. Les outils dans cet article nous allons utiliser le positionnement absolu de mesures, de contrôle lié (parfois en interne ids) ou un mélange des deux. Depuis qu'ils ont habituellement pour être formés sans l'aide de code (dans le but d'QC testeurs, les non-programmeurs), vos tests arrêter de courir après le changement.
3. Investir dans l'humain testeurs. Alors que pas un bon choix, il n'a de fin d'améliorer la qualité et commence à faire de la gestion de la pensée plus sur les coûts de refactoring de l'application.

Answer 5

Pour tester les applications WPF, il y a quelques choses avec lesquelles nous avons réussi:

1. PowerShell
2. TestPlant

et peut-être les nouvelles fonctionnalités VSTS 2010 , bien que nous ne les ayons pas essayées