Share
Le test unitaire est relativement nouveau dans les projets ActionScript. Bien que FlexUnit existe depuis un certain temps, sa configuration n’était pas intuitive et il existait de nombreuses incohérences dans la documentation. Heureusement pour nous, FlexUnit est désormais intégré à Flash Builder 4. Bien que la documentation soit encore incomplète, ce didacticiel vous aidera à configurer une suite de tests, à passer en revue plusieurs exemples de tests unitaires et à vous expliquer comment les exécuter / les analyser..
Pour ceux d'entre vous qui ne sont pas familiers avec les tests unitaires, voyons ce que Wikipedia a à dire
En programmation informatique, le test unitaire est une méthode de vérification et de validation de logiciel qui permet au programmeur de s’assurer que les unités individuelles du code source sont utilisables… Les tests unitaires sont généralement écrits et exécutés par les développeurs de logiciels pour garantir que le code respecte son design et se comporte comme prévu. . - Wikipédia
Dans ce tutoriel, je vais vous montrer comment configurer quelques tests unitaires simples sur mon framework Flash Camo. Vous devrez télécharger une copie de Flash Builder 4 (actuellement en version bêta) pour suivre. Vous voudrez également télécharger la dernière version de Flash Camo (2.2.1) à partir d’ici.
Créons un nouveau projet appelé UnitTestIntro.
Nous aurons besoin de placer notre Flash Camo SWC dans un libs / swcs dossier dans notre projet:
Enfin, nous devrons indiquer à notre projet où trouver notre SWC, cliquer avec le bouton droit de la souris sur le projet et entrer dans ses propriétés. Accédez au chemin de construction ActionScript et sélectionnez l'onglet Chemin de la bibliothèque. Cliquez sur Ajouter un dossier SWC et pointez-le sur le répertoire lib / swcs.
Maintenant que tout est configuré, nous pouvons commencer à faire des tests unitaires de base. Il est important de noter que vous ne pouvez pas effectuer de tests unitaires directement dans un projet de bibliothèque Flex. Ce n'est pas un problème pour ce projet, mais si vous voulez tester une bibliothèque de code, ce que je fais habituellement est de configurer un nouveau projet (comme nous le faisons ici), puis liez les deux projets ensemble et créez tous les tests dans le nouveau projet..
Si vous ne travaillez pas dans un projet Flex Library et souhaitez tester votre code, vous pouvez simplement créer vos tests dans le même projet. Je suggérerais de garder les deux séparés, ainsi vous pourrez voir clairement ce que sont les classes de test et quelles sont les vraies classes. Nous y reviendrons un peu plus tard quand vous verrez comment nous avons mis en place le test.
Avant de commencer quoi que ce soit, je prends un moment pour comprendre exactement ce que je vais faire. Ceci est très critique lors de la configuration des tests unitaires. Ce type de développement s'appelle Développement piloté par les tests. Je pense que je vois une autre définition à venir:
Le développement piloté par les tests (TDD) est une technique de développement logiciel qui utilise de courtes itérations de développement basées sur des scénarios de tests pré-écrits qui définissent les améliorations souhaitées ou de nouvelles fonctions. Chaque itération produit le code nécessaire pour réussir les tests de cette itération. Enfin, le programmeur ou l'équipe recompose le code pour prendre en compte les modifications. Un concept clé de TDD est que la préparation des tests avant le codage facilite les changements de retour rapides. - Wikipédia
Comme il s'agit d'une courte introduction, nous allons utiliser une bibliothèque de code existante à tester. Cependant, lorsque vous créez votre propre application, vous devez rédiger des tests afin de valider que le code fonctionne et que toute modification / refactoring ne rompt pas la mise en œuvre de votre code. Voici un aperçu des tests que nous allons effectuer:
Si vous débutez dans Flash Camo, vous pouvez consulter l'intro que j'ai écrite (parties 1 et 2), mais vous pouvez facilement suivre ce didacticiel sans aucune connaissance du fonctionnement du cadre. Encore une fois, cela va simplement être une bibliothèque de code pour nous de tester avec.
Maintenant que nous avons un plan pour faire nos tests, créons notre premier test. Faites un clic droit sur votre projet et sélectionnez Nouveau> Classe de cas de test
Vous allez maintenant voir l'assistant de création. Tous ceux qui ont déjà créé une classe dans Flex / Flash Builder doivent le connaître. Voici à quoi ressemble la fenêtre:
Parlons de quelques-uns des nouveaux champs de l'assistant. Nous pouvons commencer avec le fait que Superclass est déjà rempli pour nous: flexunit.framework.TestCase. Vous ne pouvez pas changer cela et ne devriez probablement pas. Cela ne fait qu'étendre la classe de test de base à partir du Framework de test unitaire. Ensuite, vous verrez quelques cases à cocher pour la génération de code. Laissez toutes ces cases cochées par défaut. Enfin, il y a un champ pour la classe que nous voulons tester.
Puisque nous allons tester CamoPropertySheet de Flash Camo, remplissons les valeurs suivantes dans le formulaire:
Nom: CamoPropertySheetTest Classe à tester: camo.core.property.CamoPropertySheet
Voici une capture d'écran de la façon dont j'ai créé ceci:
Hit terminé et nous devrions avoir notre premier test prêt pour nous d'ajouter un code à.
Jetons un coup d'œil au code généré par Flash Builder:
Nous commençons par avoir une propriété privée appelée classToTestRef qui est défini sur la valeur de notre CamoPropertySheet. Cela permet au test de créer une instance de cette classe et oblige le compilateur à l'importer lorsque nous exécutons notre test..
La prochaine méthode importante est installer. C'est là que nous allons créer une instance de notre classe de test, la configurer et nous assurer que tout est prêt pour que nous puissions effectuer un test..
La dernière méthode est ici abattre. C'est ici que nous allons détruire l'instance de notre classe de test une fois le test terminé. Ceci est très important lors de l'exécution de plusieurs tests.
Vous avez peut-être remarqué qu'à la fin du cours, une autre méthode appelée testSampleMethod qui est commenté. Ceci est un exemple de la façon de configurer un test unique.
Chaque test sera une méthode que nous ajoutons à cette classe. Lorsque nous exécutons le test unitaire, il appellera automatiquement toutes nos méthodes de manière dynamique, en commençant bien sûr par setUP et en finissant par abattre.
Maintenant que nous avons une compréhension de base de la configuration de TestClass, regardons-la pour l'exécuter.
Avant de pouvoir exécuter cela, nous aurons besoin d'au moins un test. Décommentons le testSampleMethod pour cet exemple.
Une fois que vous avez commenté le testSampleMethod faisons un clic droit sur notre projet et sélectionnez Exécuter en tant que> Exécuter le test FlexUnit.
Vous devriez maintenant voir la fenêtre suivante nous invitant à sélectionner le test que nous voulons exécuter.
Comme vous le voyez, ceci est configuré pour les cas où nous avons beaucoup à tester, mais pour le moment, nous n’avons qu’un testSampleMethod à exécuter. Cliquez sur Sélectionner tout et cliquez sur OK..
Une fois le test exécuté, votre navigateur Web s’ouvrira avec la page suivante:
Si vous revenez à Flash Builder, vous verrez également ceci dans le panneau Résultats de FlexUnit:
Vous voyez comme c'était facile de courir? Nous avons effectué notre premier test unitaire et nous avons déjà une seule erreur. Avant de corriger cette erreur, parlons de ces deux fenêtres..
La page Web qui était ouverte devrait se fermer automatiquement, mais parfois pas. Il s'agit d'un swf simple qui effectue nos tests en FLash et génère certaines données lues par Flash Builder afin d'afficher les résultats finaux du test. Vous pouvez ignorer cette page Web pour la plupart.
Le panneau Résultats de FlexUnit est l’emplacement où tous les résultats seront affichés, ainsi qu’un emplacement vous permettant d’organiser et de filtrer les commentaires des tests. Nous y reviendrons un peu plus tard dans le tutoriel, alors que nous avons quelque chose à tester..
Avant de pouvoir réellement commencer les tests, nous devons configurer notre classe de tests. ajoutons le code suivant à la installer méthode:
var xml: XML =; rawCSS = xml.toString (); sheet = new CamoPropertySheet (); sheet.parseCSS (rawCSS);
Nous devrons également configurer certaines propriétés:
feuille var privée: CamoPropertySheet; private var rawCSS: String;
Voici ce qui se passe dans cette configuration: pour que nous puissions tester notre CamoPropertySheet, nous aurons besoin de CSS comme chaîne. Normalement, je charge le CSS à partir d'un fichier externe, mais comme nous faisons un test simple, je crée un nouveau bloc XML et place le texte CSS à l'intérieur du premier nœud. Normalement, vous n'avez pas à insérer du code CSS dans CamoPropertySheet à l'intérieur de XML, mais lorsque vous travaillez avec de grandes chaînes dans l'éditeur, je trouve qu'il est plus facile d'utiliser XML, car vous pouvez envelopper le texte et conserver une certaine mise en forme..
Ensuite, vous verrez que nous définissons notre propriété rawCSS sur la valeur de chaîne du fichier xml. Cela convertit le XML en une chaîne. Ensuite, nous créons un nouveau CamoPropertySheet. Enfin, nous demandons à la feuille d’analyser le rawCSS.
C'est tout ce qu'il y a à mettre en place cette classe particulière. La configuration est différente pour chaque classe que vous testez. Il est important de démontrer que nous faisons le strict minimum pour qu'une classe soit prête à être testée. Nous ne pouvons pas tester une classe sans valeurs.?
Allons droit au but. Une fois qu'une CamoPropertySheet a analysé avec succès une chaîne css, nous pouvons demander un tableau de noms de sélecteurs pour vérifier que tout a bien été analysé. Pour ceux qui ne connaissent pas le jargon CSS, un sélecteur est le nom d’un style css, c’est-à-dire baseStyle … aurait un sélecteur appelé style de base.
Voici à quoi ressemblerait notre test en anglais:
Remplaçons notre testSampleMethod avec la méthode suivante:
fonction publique testParseCSS (): void var selectors: Array = sheet.selectorNames; total de var: Nombre = selectors.length; assertEquals (total, 6);
Comme vous pouvez le constater, nous obtenons un tableau de noms de sélecteurs. Ensuite, nous obtenons le total et introduisons notre premier test assetEquals. Dans la prochaine étape, je vais expliquer les méthodes assertMethod plus en détail, mais exécutons ceci et voyons si le test réussit.
Lorsque vous exécutez le test, vous devriez voir ce qui suit dans le panneau Résultats de FlexUnit:
Nice, notre test a réussi. Nous avons reçu le nombre exact de sélecteurs auxquels nous nous attendions. Regardons quels tests d'affirmation nous pouvons utiliser.
Dans les tests unitaires, nous exécutons des assertions. Chaque assertion gère un type de test particulier. Voici un bref aperçu des assertions les plus courantes que vous utiliserez probablement:
Maintenant, avant de tester un exemple de chacun, configurons notre abattre méthode.
Ce sera une étape très courte mais très importante. Ajoutons la ligne suivante à notre abattre méthode après super.tearDown ():
sheet = null;
En gros, cela supprime la référence à notre CamoPropertySheet afin que le récupérateur de place puisse l'enlever..
Vous devriez toujours configurer votre abattre en particulier lors de l'exécution de plusieurs classes de test ou d'une grande suite de tests.
Nous avons déjà vu un exemple de cela avant à l'étape 7, mais passons en revue et ajoutons un autre assertEquals. Voici le prochain test que nous allons effectuer:
Pour exécuter le test, ajoutons la méthode suivante:
Accentsconagua
fonction publique testToString (): void var comprimCSS: String = "baseStyle x: 10; y: 10; width: 100; height: 100; padding: 5; margin: 10; baseStyle .Button x: 0; y : 0; background-color: # 000000; # playButton background-color: #FFFFFF; background-image: url ('/ images / full_screen_background.jpg'); # fullScreenButton background-color: # FF0000; background- image: url ('/ images / full_screen_background.jpg'); # playButton: over background-color: # 333333; interactive curseur: main; "; assertEquals (sheet.toString (), compriméCSS); Exécutez maintenant le test unitaire et assurez-vous de sélectionner les deux tests dans les cases à cocher. Les nouveaux tests ne sont pas automatiquement sélectionnés. Si tout se passe bien, vous devriez voir un succès et que 2 tests ont été exécutés.
Nous pouvons faire un test simple pour nous assurer que si nous demandons un sélecteur qui n'existe pas, nous obtenons une valeur fausse. Voici comment nous ferions cela avec le CamoPropertySheet:
Voici le code pour effectuer le test:
fonction publique testEmptySelector (): void var selector: PropertySelector = sheet.getSelector ("testSelector"); var existe: Boolean = (selector.selectorName == PropertySelector.DEFAULT_SELECTOR_NAME)? faux vrai; assertFalse (existe); Comme vous pouvez le constater, nous demandons simplement un faux nom de style testSelector. Nous vérifions si le nom du sélecteur est le nom par défaut appliqué quand aucun sélecteur n'est trouvé. Enfin, nous passons la variable existe à la affirmer méthode. Lorsque vous exécutez ceci, vous devriez maintenant voir 3 passes totalisant un succès.
Ensuite, nous voulons nous assurer que la valeur textuelle de notre CamoPropertySheet n’est jamais nulle. Voyons comment structurer notre test:
Voici notre méthode de test:
fonction publique testCSSValue (): void assertNotNull (sheet.toString ());
C’est assez simple, alors quand vous lancez le test, nous devrions maintenant avoir 5 succès. Chaque fois que nous exécutons le test, nous pouvons vérifier le nom de nos tests de méthode en cliquant sur le dossier Suite par défaut de notre panneau de résultats FlexUnit dans Flash Builder..
Dans ce prochain test, nous allons suivre le test du sélecteur vide pour vérifier que chaque sélecteur a un selectorName.
Voici la méthode de test:
fonction publique testSelectorsHaveNames (): void var selectorA: String = sheet.getSelector ("testSelector"). selectorName; var selectorB: String = sheet.getSelector ("baseStyle"). selectorName; assertNotUndefined (sélecteurA, sélecteurB); Les deux premières lignes sont explicites. nous demandons simplement deux sélecteurs et l'un d'eux, nous le savons, n'existe pas. Lorsque nous faisons l'affirmation, vous remarquerez cependant que nous transmettons deux valeurs au lieu de la valeur normale que nous avons effectuée jusqu'à présent. Il ne s'agit pas d'un exemple unique. En fait, chacune des méthodes d'assertion vous permet de transmettre un nombre quelconque de valeurs à tester. Ici, nous nous assurons simplement que selectorA et selectorB ne sont pas indéfinis.
Voici un exemple de comparaison stricte de deux objets. Ici, j'utilise des chaînes qui ne sont peut-être pas la meilleure utilisation de cet exemple, mais il est bon de voir le test en action. Qu'allons nous faire?
fonction publique testClone (): void var clone: CamoPropertySheet = sheet.clone () en tant que CamoPropertySheet; assertStrictlyEquals (sheet.toString (), clone.toString ());
Comme vous pouvez le constater, nous appelons la méthode clone de CamoPropertySheet pour récupérer une copie exacte de la PropertySheet. Ensuite, nous passons le test d’assert en appelant le toString méthode sur chacun. Si le test CSS renvoyé est identique, nous avons réussi le test..
Maintenant, nous voulons tester que lorsque nous demandons un sélecteur, il a une propriété que nous attendons. Voici le test:
Voici la méthode de test:
fonction publique testSelectorHasProperty (): void sélecteur de var: PropertySelector = sheet.getSelector ("baseStyle"); assertTrue (selector.hasOwnProperty ("x")); Comme vous pouvez le voir ici, nous attendons notre style de base sélecteur d'avoir la propriété x. Si cela existe, nous pouvons supposer qu'il a été correctement analysé à partir de la chaîne CSS. Depuis qu'il existe nous avons passé ce test.
Chacun de ces tests devient explicite quant à la façon dont vous les implémentez. Voyons ce qui se passe lorsque nous échouons à un test au cours des deux prochaines étapes..
Nous allons maintenant tester indéfini, mais Flash Camo a été conçu pour ne pas renvoyer indéfini. Donc, le test suivant va échouer. Voyons ce que nous allons tester.
Voici le code pour le test:
fonction publique testClear (): void sheet.clear (); assertUndefined (sheet.toString ());
Maintenant, exécutons ce test et passons à l'étape suivante pour discuter des résultats..
Si vous avez effectué l'étape précédente et exécuté le test unitaire, le panneau Résultats du FlexUnit devrait s'afficher comme suit:
Notez comment nous avons 1 échec de notre testClear méthode?
Si vous double-cliquez sur le test ayant échoué dans le panneau Résultats du test, vous passez directement à la source du test ayant échoué. C'est un excellent moyen de corriger votre erreur ou de modifier le test pour qu'il n'échoue pas. Il n'y a pas grand chose de plus à faire échouer un test que ça. Chaque test qui échoue apparaîtra dans ce panneau. Vous pouvez indiquer au panneau d'afficher uniquement les tests ayant échoué en cliquant sur le point d'exclamation rouge ci-dessus, indiquant le nombre d'erreurs que vous avez commises.
Maintenant que nous avons échoué à ce test, remplacez-le par le suivant:
fonction publique testClear (): void sheet.clear (); assertEquals (sheet.toString (), "");
Si vous relancez le test, vous verrez qu'il passera. Maintenant, vous avez 7 tests sur 7 réussis et cette classe fonctionne avec succès. Parlons de la configuration des tests unitaires pour vos propres classes personnalisées.
Jusqu'à présent, nous avons testé une bibliothèque précompilée, mais vous voudrez peut-être savoir comment cela fonctionnera dans vos propres classes. Nous allons modifier un peu la classe doc puis exécuter un test unitaire personnalisé sur celle-ci. Pour commencer, remplacez tout le code de la classe UnitTestIntro par ce qui suit:
package import flash.display.Sprite; Classe publique UnitTestIntro étend Sprite private var _firstName: String; private var _lastName: String; private var _loggedIn: Boolean; fonction publique UnitTestIntro () _firstName = "Jesse"; _lastName = "Freeman"; fonction publique get firstName (): String return _firstName; fonction publique get lastName (): String return _lastName; fonction publique isLoggedIn (): Boolean return _loggedIn;
Une fois le code en place, faites un clic droit sur UnitTestIntro et sélectionnez Nouveau> Classe de cas de test. Si vous regardez l'assistant cette fois, vous verrez que tous les champs sont remplis pour nous:
Cette fois, au lieu de cliquer sur Terminer, cliquez sur Suivant et regardez dans la fenêtre suivante:
Ici, vous pouvez sélectionner toutes les méthodes publiques de cette classe à tester. Notez que nos getters pour firstName et lastName ne font pas partie de cette liste. Les tests unitaires ne peuvent être effectués que sur des méthodes publiques. En outre, vous verrez toutes les méthodes héritées de la classe. Nous avons donc les méthodes Sprite / DisplayObject ici puisque notre classe doc étend Sprite. Sélectionner isLoggedIn et frapper la finition.
Si vous faites défiler l'écran jusqu'en bas de la nouvelle classe de test qui vient d'être générée, vous verrez qu'elle a été automatiquement ajoutée à un testMethod pour isLoggedIn..
Lors du test de votre propre code, Flash Builder peut vous aider à automatiser le processus d’échafaudage de vos tests. C'est une aide précieuse pour les classes nombreuses qui ont beaucoup de méthodes..
Vous devez maintenant bien comprendre le fonctionnement des tests unitaires dans Flash Builder. Vous pouvez même être prêt à commencer à configurer votre propre test. Il y a beaucoup de choses que je n'ai pas pu couvrir dans ce court tutoriel, voici donc quelques points à garder à l'esprit lors de la création de vos tests.
Comme vous pouvez le constater, la configuration des tests unitaires est très simple, mais la création d’applications tournant autour du développement piloté par les tests est une forme d’art à part entière. Espérons qu'après cette introduction, vous serez à l'aise avec la configuration d'un test simple pour valider que votre code fonctionne comme prévu. Comme vous comptez de plus en plus sur Unit test, le nombre de bogues dans votre code va considérablement diminuer. Tant que vous pensez coder pour réussir un test, en gardant vos méthodes simples et en validant souvent vos tests unitaires, vous serez sur la bonne voie pour construire un code plus stable..
Merci d'avoir lu.
