Existe-t-il un moyen d’automatiser le test des formulaires Windows?

Je suis familier avec nunit pour les tests unitaires de la couche métier, mais je cherche maintenant à automatiser le test de la couche d’interface graphique des formulaires gagnants.

J’ai vu watin et le watin recorder pour automatiser les tests sur une application Web en accédant aux commandes et en les automatisant. Cependant, j’ai du mal à trouver un équivalent pour Windows Forms (écrit en c # ou vb.net) qui est de préférence open source.

Existe-t-il ou est-ce que tous les produits sont basés sur l’enregistrement de la souris et du clavier?

Mise à jour: J’ai regardé ce blog sur le blanc et il semble que le genre de chose que je recherche. Le billet de blog soulève des problèmes, mais comme le blanc est seulement dans la version 0.6, ils peuvent être résolus. Soyez intéressé si d’autres personnes ont utilisé du blanc ou d’autres pour comparer.

Découvrez http://www.codeplex.com/white et http://nunitforms.sourceforge.net/ . Nous avons utilisé le projet White avec succès.

Même réponse à une question précédente

TestComplete d’AutomatedQA est une bonne application de test pour automatiser les tests d’interface graphique. Il ne prend pas uniquement en charge Windows Forms, vous pouvez donc le réutiliser pour d’autres applications. Ce n’est pas open source et c’est le meilleur que j’ai trouvé. Je n’ai pas vu d’équivalent open source à WatiN. Il a un essai gratuit, car vous décidez si vous l’aimez ou non. La principale raison pour laquelle je suis parti avec ça, c’est que c’est vraiment rentable par rapport aux autres applications de test.

Comme nouvelle alternative, je peux vous donner FlaUI ( https://github.com/Roemer/FlaUI ). Il s’agit essentiellement d’une réécriture complète du blanc avec plus de fonctionnalités et une base de code propre.

À ma connaissance, White est une couche d’abstraction au-dessus du cadre de Microsoft UI Automation . J’ai écrit une couche similaire que nous utilisons en interne sur nos projets et cela fonctionne très bien. Donc, blanc serait certainement un coup d’oeil

Microsoft a publié la source dans UI Automation, donc si nécessaire, vous devriez pouvoir déboguer le long de la stack si nécessaire.

Ce qui est vraiment génial, c’est qu’avec le coût de la licence, vous pouvez augmenter et exécuter autant de machines que vous le souhaitez pour l’exécution.

Nous courons à l’intérieur de VSTS et lions nos résultats aux exigences, mais vous pouvez utiliser c # express et nUnit et obtenir des outils et des langages de première classe pour un coût minime ou nul.

Voici quelques liens de MSDN Magazine sur le code de test automatique:

  • Utilisation de UIAutomation Bugslayer Mars 2007
  • Utilisation de PowerShell Test Run Décembre 2007
  • Testeur, un utilitaire pour enregistrer les clics de souris et les frappes de touches, puis les lire en arrière et contrôler le comportement des programmes. Excellent pour le code non géré. Utilise les poignées Windows et peut donc ne pas fonctionner correctement pour le code managé. Bugslayer Mars 2002.

Vous pouvez consulter le cadre Microsoft UI Automation . Cela a été inclus dans .NET depuis la version 3.0. C’est en fait ce que le framework White utilise de toute façon.

Vous pouvez envisager d’utiliser l’interface utilisateur codée , une fonctionnalité intégrée de Visual Studio et une partie de l’automatisation de l’interface utilisateur:

Les tests automatisés qui pilotent votre application via son interface utilisateur sont appelés tests d’interface codée (CUIT) . Ces tests incluent des tests fonctionnels des contrôles de l’interface utilisateur. Ils vous permettent de vérifier que l’application entière, y compris son interface utilisateur, fonctionne correctement. Les tests codés de l’interface utilisateur sont particulièrement utiles lorsqu’il existe une validation ou une autre logique dans l’interface utilisateur, par exemple dans une page Web. Ils sont également fréquemment utilisés pour automatiser un test manuel existant.

[…] une expérience de développement typique peut être une expérience dans laquelle, initialement, vous construisez simplement votre application (F5) et cliquez sur les contrôles de l’interface utilisateur pour vérifier que les choses fonctionnent correctement. Vous pouvez ensuite décider de créer un test codé afin de ne pas avoir à continuer à tester l’application manuellement. Selon la fonctionnalité particulière testée dans votre application, vous pouvez écrire du code pour un test fonctionnel ou pour un test d’intégration qui peut ou non inclure des tests au niveau de l’interface utilisateur. Si vous souhaitez simplement accéder directement à une logique métier, vous pouvez coder un test unitaire. Toutefois, dans certaines circonstances, il peut être utile d’inclure le test des différents contrôles de l’interface utilisateur dans votre application. Un test de l’interface utilisateur codée peut automatiser le scénario initial (F5), en vérifiant que le roulement de code n’a pas d’impact sur les fonctionnalités de votre application.

Pour en savoir plus: https://docs.microsoft.com/fr-fr/visualstudio/test/use-ui-automation-to-test-your-code