3

Je compile et gère un ensemble de composants Flash qui sont distribués aux éditeurs et leur permettent de s'intégrer à notre système. Actuellement, le composant n'a pas d'interface utilisateur et contient simplement du code compilé pour interroger nos serveurs système, analyser la réponse et modifier les paramètres envoyés dans la requête. Il existe une version As2 et des versions AS3 pour Flex et CS3. Notre flux de travail typique est comme ceci:Tests automatisés (hors interface utilisateur) pour le composant Flash existant

1.) charger le composant 2.) paramètres définis sur le composant 3.) dire le composant à interroger notre système 4.) attendent un événement disant que la réponse a été reçu et analysé 5.) méthodes d'appel sur le composant pour récupérer et utiliser des données analysées

Nous avons beaucoup parlé récemment de l'automatisation des tests de ces composants, et il semble y avoir beaucoup de buzz autour des cadres comme AsUnit et FlexUnit. Cependant, je n'ai jamais été capable de comprendre comment je pourrais utiliser efficacement l'un d'entre eux. Les exemples et les tutoriels ne lésinent jamais sur les exemples du monde réel et fournissent à la place plusieurs classes et un code excessif pour tester si un exemple de fonction renvoie num1 + num2. La seule chose que je peux deviner est que ces frameworks de test sont destinés à être implémentés dès le début, avec la planification de la suite de tests, du testeur et des cas de test intégrés au début du développement. Un test automatisé de notre composant devrait s'assurer que les propriétés ont été correctement définies, ces propriétés ont été envoyées dans la demande à notre système, la réponse reçue était correcte compte tenu des paramètres envoyés, les données analysées incluent des informations correctes, et non des erreurs, des mauvaises réponses ou des boucles d'analyse infinies sont provoquées. Ma question est la suivante: y a-t-il un moyen d'automatiser le test d'un composant Flash existant, largement répandu, sans le retravailler complètement pour l'adapter à un cadre de test? Ou ai-je mal compris les cadres de test et cela est déjà possible?

MISE À JOUR: Merci pour les réponses. J'ai commencé à intégrer mon composant avec AsUnit et je pense avoir une très bonne compréhension de la façon dont cela peut m'aider. Cependant, AS2 AsUnit ne supporte pas les cas de test asynchrones, et j'ai du mal à trouver un framework de test unitaire AS2. Les tests asynchrones sont VRAIMENT importants pour ce projet. Quelqu'un at-il des recommandations pour un cadre différent? Merci!

Répondre

3

Nous utilisons FlexUnit sur notre projet et j'en suis assez content. En supposant que votre projet a été conçu avec un degré de couplage assez lâche, vous ne devriez pas avoir à changer du tout (ou pas du tout) pour tester votre code. Si vous utilisez déjà un framework MVC comme Cairngorm ou PureMVC, FlexUnit devrait s'intégrer assez facilement. Je dirais cependant que mon expérience avec les tests unitaires Flash/Flex n'est pas aussi positive que celle avec d'autres langages tels que Ruby ou .NET pour trois raisons. Tout d'abord, un tel degré de code ActionScript est lié à l'interface utilisateur, et ce type de code est difficile, voire impossible à tester. Une autre raison est que le coureur de test ne se prête pas bien à être branché dans un environnement d'intégration continue tel que CruiseControl.NET ou CruiseControl.rb puisqu'il nécessite un humain pour l'exécuter et cliquer sur les boutons. Enfin, un énorme avantage des tests unitaires est généralement que vous pouvez l'exécuter avec un outil d'analyse de couverture tels que NCover ou rcov. Flash/Flex ne se prête pas à ce type d'analyse sans un compilateur modifié tel que Flexcover.

1

Alors que je ne ai jamais eu la chance de travailler avec un testeur unitaire en actionscript, au travail que nous avons créé un cadre qui:

  1. compilé le script (s) à l'intérieur d'une application de test, dans notre cas avec flex
  2. mis en place une minuterie (chien de garde) l'application, en cas de défaillance de la boucle
  3. couru l'application qui, à son tour:
    • connecté à un back-end PHP pour obtenir un test
    • alimenté le test à la composante
    • lire les résultats et les a renvoyés
  4. le chien de garde se lancer et tuer l'application sur celui qui est arrivé en premier:
    • timer a manqué (délai raisonnable)
    • demande
    • a renvoyé les résultats
  5. s'il y avait d'autres tests à exécuter, goto 2.

Certainement pas élégant, mais a fait le travail (ce qui était avec des scripts AS1)

2

Je suis heureux de vous entendre allé avec AsUnit! AsUnit est le seul framework de test unitaire qui vous donnera une expérience cohérente dans ActionScript 2 et ActionScript 3. Il n'a aucune dépendance sur les frameworks externes - en particulier Flex, et il ne devrait pas y avoir de réel problème avec la création de tests pour votre projet après coup.

Les dernières builds AsUnit n'ont le soutien pour le test asynchrone dans ActionScript 2. La branche AS25 se trouve ici:

http://github.com/lukebayes/asunit

+0

merci Luc! Je vais devoir jeter un autre coup d'oeil à ça alors! – nerdabilly