Quel est le nouveau cadre le plus maintenu dans .NET pour écrire des tests d'acceptation?

Veuillez considérer Ranorex comme l'un des outils assez nouveaux.

http://www.ranorex.com/

Ils font un excellent travail dans la fourniture d'un ensemble complet d'outils comprenant l'API test de l'unité, le moteur automatisé plus un enregistreur de test. En bref - vous écrivez vos tests en C # ou vous les "enregistrez" à l'aide de l'enregistreur et que l'enregistreur les écrit comme code C #.

Ensuite, vous les "répondez", exécutant votre code C #. Vous créez autant d'affirmations que vous le souhaitez et l'API d'automatisation vous permet d'automatiser tout ce qui est visible à l'écran.

Grand outil pour ATDD, nous l'utilisons depuis un certain temps et nous sommes satisfaits.

Nous venons de commencer à utiliser fitnesse , et jusqu'à présent, je suis satisfait de la décision. Un très bref aperçu:

1. Vous écrivez vos tests dans un wiki.
2. Vous écrivez un module "Fixture de test" (qui peut être un ensemble C #) qui Fournit le pont entre les «tests» dans le wiki et le SUT (Système sous test).
3. Lorsque vous exécutez les tests, le moteur Fitnessse utilise la réflexion pour traduire les tests Wiki en appels vers votre montage de test, qui appelle à son tour le SUT. Les valeurs de retour sont retournées sur le wiki afin que vous puissiez les "affirmer".

   L'interface publique du code de test de test est en vigueur la langue que vous utilisez pour écrire des tests dans le wiki. Je ne sais pas si j'expliquais très bien cela, mais il y a beaucoup de ressources et de vidéos sur le Web. Je recommande Celui-ci de Bob Martin, auteur de Fitessse.

   J'ai choisi Fitnessse pour un certain nombre de raisons:

   • Cadre bien établi
   • fonctionne avec .NET Utilisation du plug-in FITSHARP: http://fitnesse.org/fitnesse.dotnet < / li>
   • Parce que les tests du wiki sont écrits dans la langue que vous définissez dans votre code de configuration, ils sont lisibles Les tests
   • peuvent être appelés via une ligne de commande, que nous souhaitons pour une intégration continue.
   • robuste 1: Si l'interface de la SUT change, il vous suffit de modifier le code de test de test, pas des tests
   • robuste 2: Nous ne testons pas au niveau UI volatil.

     Il faut un peu de temps pour s'y habituer, mais je trouve cela beaucoup plus fiable que notre concept actuel de tests à travers l'interface utilisateur. Nous le faisons actuellement dans une application à domicile, qui fonctionne en lisant des actions d'assurance-emploi pré-enregistrées et en comparant des coups d'écran. Lorsque les tests sont rouges, il est rarement parce que la SUT est effectivement cassée. Généralement, nous avons des problèmes de synchronisation avec les contrôles d'interface utilisateur ne réagissant pas instantanément, nous devons donc construire des retards entre les actions d'assurance-chômage, ce qui signifie qu'il faut toute la nuit pour exécuter la suite complète des tests.