Expériences avec UI Automation et WPF [fermé]

Question

Nous développons actuellement une application assez volumineuse basée sur WPF et souhaiterions inclure des tests d'interface utilisateur automatisés dans notre suite de tests (qui contient déjà un certain nombre de tests unitaires).

Le UI Automation Framework à partir de Microsoft semble en partie comme un choix parfait pour lancer et interagir par programme avec l'application dans une configuration de test. Cependant, j'ai eu du mal à trouver des références solides pour les échantillons et les expériences avec la technologie. Les articles et les petits échantillons disponibles sur MSDN ne suffisent pas pour me convaincre que c'est un choix solide.

Alors, est-ce que quelqu'un a des expériences réelles en utilisant le framework UI Automation dans sa suite de tests? Quelles sont les mises en garde et les pièges? Toutes les meilleures pratiques en matière de rédaction de scripts de test peuvent "enregistrer et rejouer". dans un format scriptable, dans quelle mesure devriez-vous faciliter les tests à partir de l'application, comment l'avez-vous intégré dans la construction automatique? Devrions-nous regarder dans une autre direction que la UI Automation Framework?

N'hésitez pas à poster vos expériences ici ou à faire un lien vers de bonnes références que j'ai peut-être manquées

Answer 1

Où je travaille, nous venons juste de commencer à évaluer des outils de test pour notre système. Nous avons découvert un outil appelé blanc , qui utilise UI Automation Framework. Notez que le blanc a aussi une fonction d’enregistrement, même si je pense qu’il a des problèmes et est en cours de développement.

Ce que nous avons essayé de faire, c’est de les configurer pour qu’ils ressemblent à des tests unitaires, par exemple [TestFixture] [Test] , etc. nous avons ensuite pu les exécuter en même temps que les tests unitaires.

Nous avons constaté qu'il peut être difficile d'accéder à certains composants de votre fenêtre, mais nous n'avons pas vraiment eu l'occasion de rechercher pourquoi.

Si le fait de payer pour le logiciel ne vous dérange pas, je vous recommanderais alors TestComplete .

Answer 2

Je suis en train de faire l'automatisation d'interface utilisateur d'une application WPF au travail. J'utilise White et IronRuby et cela fonctionne très bien. J'ai écrit comment je l'ai fait ici: http://www.natontesting.com/2010/02/17/how-to-test-a-wpf-app-using-ironruby-and-white/

Answer 3

Nous sommes d'abord allés avec du blanc, puis nous nous en sommes éloignés. Il essaie d'être générique et abstrait sur l'API Win32, Winforms, les applications Java et l'API d'automatisation MS UI. L’API d’automatisation MS UI tente également d’être générique et abstraite sur l’application win32, les winforms et WPF, de sorte que vous vous retrouvez dans le "plus petit commun dénominateur-du plus petit commun dénominateur". scénario.

Cela a eu pour résultat que l'API de recherche d'éléments blancs n'était tout simplement pas assez flexible pour rechercher les différents éléments d'interface utilisateur que nous devions trouver, et qu'elle n'exposait pas suffisamment d'éléments de l'infrastructure d'automatisation d'interface utilisateur sous-jacente pour que nous puissions faire quoi que ce soit. utile avec elle.

Nous avons finalement opté pour une sorte de cadre développé en interne; Nous utilisons directement le framework MS UIAutomation, mais nous disposons de méthodes d'extension et de classes d'assistance pour gérer les scénarios non traités. (Entrée clavier et souris, principalement).

Remarque: nos scripts de test et notre framework maison utilisent tous IronRuby. La capacité de Ruby à ajouter des méthodes aux classes existantes et sa syntaxe flexible (combinée à method_missing) sont impressionnantes pour ce genre de choses.