Test de fumée automatisé d'une application WPF? [fermé]

Question

Nous avons une application WPF sur laquelle nous aimerions exécuter des tests de fumée automatisés. Des tests simples comme charger un document, enregistrer un document, etc. Je me demandais si quelqu'un pourrait suggérer des travaux de cadre existants ou des applications qui pourraient aider à cela.

Merci!

Answer 1

Pour les frameworks de test, NUnit et MSTest sont bons. MSTest a l'avantage d'intégrer très volontiers Visual Studio, ce qui facilite les choses un peu. (Il existe des addins nunit disponibles pour vs, mais ils sont tout aussi intégrés que mstest).

Pour ce qui est de la manière dont vous écrivez le test, si vous avez écrit votre application conformément au Modèle MVVM Il est très simple de faire en sorte que vos tests créent et exécutent votre application à l'aide des modèles et des commandes de vue sans créer réellement de vue.

Même si vous n'avez pas utilisé MVVM, j'espère que vous avez toujours extrait vos couches logiques de votre interface graphique afin que vos tests puissent les appeler sans trop de difficulté.

En ce qui concerne les tests d’interface graphique, vous pouvez consulter la MS. UI Automation qui devrait vous permettre d’automatiser des parties de votre interface utilisateur afin de lui permettre d’effectuer des tests. Il existe un article de blog ici sur comment y aller, et un article ici . Il existe également des cadres commerciaux qui superposent les éléments d'automatisation de l'interface utilisateur pour les rendre un peu plus faciles. testautomationfx est un exemple.

Answer 2

En tant que test parlé, vous devriez être "de bout en bout", puis j’examinais des outils de test d’interface utilisateur automatisés tels que Test complet, plutôt que des outils de test unitaire & # 8211; scripter la création d'une machine virtuelle puis exécuter vos programmes d'installation est une autre bonne option. Vous avez parlé de test devrait inclure le programme d'installation de votre application, car ils ne sont généralement pas couverts par les tests unitaires, ni utilisés par vos développeurs.

Vous essayez d'éviter que vos testeurs passent du temps sur & # 8220; sans espoir & # 8221; construit & # 8211; d'où la nécessité d'inclure le programme d'installation.

Pensez à tous les & # 8220; daft & # 8221; raisons qui empêchent votre équipe de test d’être productive après avoir passé du temps à installer une nouvelle version & # 8211; combien d’entre eux pouvez-vous inclure dans un système automatisé sans que les tests échouent en raison de modifications de l’application.

De nombreuses personnes commettent l’erreur d’essayer de couvrir trop de sujets lors d’un test de rayons & # 8211; Tests approfondis & # 8221; qui couvre toute votre logique devrait figurer dans les tests unitaires et / ou les "tests d'histoire" et # 8221; pas votre test parlé.