:: Catégories

  • actionscript 3
  • Air
  • Flash
  • Flex
  • molehill
  • Non classé
  • papervision
  • Web

:: Derniers articles.

  • Nouveau Android Flash Game : Kick The Ducks !
  • Démo – Client FTP en Flex
  • Démo Molehill – particules
  • [TUTO] AS3 + APPARAT / TDSI, accélérez vos projets !
  • [FIXED] SecurityError: fileWriteResource
  • [Tutorial] Techniques d’optimisations en AS3
  • [Tutorial] Un client FTP en AS3 sous RoboLegs + SwfStudio – partie 2
  • [Tutorial] Un client FTP en AS3 sous RoboLegs + SwfStudio – partie 1

:: Tags

  • 3d actionscript3 ACTUce android as3 client code demo ducks Flash Flex flexunit framework ftp game jeux kick molehill optimisations particules robotlegs swfStudio tests unitaires the

:: Sites Exoa

  • Home
  • actionscript 3
  • Air
  • Flash
  • Flex
  • molehill
  • Non classé
  • papervision
  • Web

exoa labs

[TUTORIAL] extreme Programming, les tests unitaires ou tests de regression

Aucun commentaire - mar 12th, 2010 - Flash, actionscript 3

La plus part du temps les développeurs pour tester un code vont utiliser des traces temporaires dans l'application pour espérer que le code retourne bien la bonne valeur ou effectue le bon comportement. Sachant que c'est lui qui effectue le test de manière manuelle :
> je clic un peu par la,(clic) voila pour voir ce qui se passe… ouf! j'ai eu chaud, ca marche!.

Les developpeurs sont très motivés en début de projet et ils en mettent partout, mais quand la date de livraison approche ces tests diminuent voir même disparaissent pour faire vite… au profit de bien faire.

Le gros inconvenant concernant l'utilisation des traces temporaires sont leurs limites d'utilisation, et ne peuvent empêcher une régression.

Il existe une solution que nous propose l'extreme Programming sous la forme de tests unitaires ou tests de regression.

Cette pratique ou cette philosophie de travail consiste à écrire un test avant même d'écrire le code qui pourra le passer. Cela permet surtout au développeur de travailler par étape parce que je sais très bien que ce dernier aime se lancer corps et âme dans le code en voulant faire tout en même temps.

Cette pratique va l'obliger a découper son travail et ainsi procéder par étape.

Pour résumer, les tests unitaires apportent un feedback beaucoup plus rapidement que l'utilisation des traces temporaires et permet une division du travail à effectuer.

Un point qui m'est important et qui doit l'être pour vous aussi si les tests unitaires vous intéressent : faites le code le plus simple qui soit. Les optimisations se feront après.

Alors attention, la mise en pratique des tests unitaires n'est pas chose facile, puisque la première chose à apprendre c'est l'utilisation d'un framework de tests mais surtout à rendre son code testable.

Nous allons voir à travers l'utilisation du framework ACTUce la mise en place de tests unitaires.

Les tests unitaires sont organisés dans des classes de tests et une classe de test par classe à tester. ASTUce tourne autour de trois classes qui ont pour rôle :

* MiniRunner : le lanceur de tests.
* TestCase : la classe de test qui implémente l'interface ITest
* TestSuite: qui gère une collection de classes de tests (Design pattern Composite) :

Un exemple de test unitaire

Prenons l'exemple de la création d'un carnet d'adresses mais plus précisement l'ajout et le retrait d'un contact (Nom, Prenom, Email, Téléphone) existant du carnet.

- L'ajout d'un contact :

  1.  
  2. var carnet:Carnet = new Carnet();
  3. var contact:Contact = new Contact("Dubreuil","Henry","h.dubreuil@free.fr","01.75.34.24.10");
  4. carnet.addContact(contact);
  5.  
  6. assertEquals(1,carnet.count);
  7.  

ici la classe Contact n'est qu'une structure d'informations, elle n'a pas de comportements, il n'est pas utile de la tester.

La stucture d'un test est toujours la même, déclaration des objets utiles aux tests et une liste d'assertions.

Le test unitaire nous permet implicitement d'obtenir l'interface de nos classes:

  1.  
  2. class AddressBook {
  3. function AddressBook() {
  4.  
  5. }
  6.  
  7. function addContact(c:Contact) {
  8. // Code ...
  9. }
  10. }
  11.  
  12. class Contact {
  13. var last:String;
  14. var first:String;
  15. var email:String;
  16. var phone:String;
  17.  
  18. function Contact(last:String, first:String, email:String, phone:String) {
  19. this.last = last;
  20. this.first = first;
  21. this.email = email;
  22. this.phone = phone;
  23. }
  24.  
  25. function toString():String {
  26. return "Fiche contact: " + fisrt + " " + last + "\n" + phone + " <" + email + ">";
  27. }
  28. }
  29.  

Nous allons maintenant écrire une classe de test qui doit hériter de la classe TestCase :

  1.  
  2. import buRRRn.ACTUce.TestCase;
  3.  
  4. class TestAddressBook extends TestCase {
  5. function TestAddressBook(name:String) {
  6. super(name);
  7. }
  8.  
  9. function testAddContact() {
  10. var carnet:Carnet = new Carnet();
  11. var contact:Contact = new Contact("Dubreuil","Henry","h.dubreuil@free.fr","01.75.34.24.10");
  12. carnet.addContact(contact);
  13.  
  14. assertEquals(1,carnet.count);
  15. }
  16.  
  17. function testInstancied() {
  18. var carnet:Carnet = new Carnet();
  19.  
  20. assertNotNull(carnet);
  21. }
  22. }
  23.  

Le constructeur doit avoir un parametre de type String que nous passons au constructeur de la classe TestCase. Les tests sont implémentés dans la classe sous la forme de méthodes.

Tout à l'heure nous avons parlé d'une liste d'assertions, des méthodes nous permettant d'effectuer des tests, dans notre cas nous en avons utilisé une seule mais il en existe plusieurs, à savoir :

* assertTrue(condition:Boolean) : verifie si la condition est vraie.
* assertFalse(condition:Boolean) : l'opposé de assertTrue.
* assertNotNull(obj:Object) : verifie si l'objet existe.
* assertNull(obj:Object) : l'opposé de assertNotNull.
* fail(message:String) : permet d'échouer un test et d'afficher un message.

la liste n'est pas complète bien entendu…

A chaque méthode de test correspond à une instance de la classe test, voici un exemple faux mais utile pour comprendre le cycle de vie d'un test :

  1.  
  2. var test1:TestAddressBook = new TestAddressBook();
  3. test1.testAddContact();
  4.  
  5. var test2:TestAddressBook = new TestAddressBook();
  6. test2.testInstancied();
  7.  

Nous sommes amenés dans les tests à vouloir initialiser des variables, objets etc… Il nous suffit pour cela de redéfinir deux méthodes, une qui initialise le test l'autre qui le nettoie : setUp et tearDown. Dans le cas de notre test nous devons instancier à chaque fois une classe Carnet, nous pouvons donc factoriser le tout dans la méthode d'initialisation setUp :

  1.  
  2. import buRRRn.ACTUce.TestCase;
  3.  
  4. class TestAddressBook extends TestCase {
  5. private var carnet:Carnet;
  6.  
  7. function TestAddressBook(name:String) {
  8. super(name);
  9. }
  10.  
  11. // Initialise le test
  12. function setUp() {
  13. carnet = new Carnet();
  14. }
  15.  
  16. function testAddContact() {
  17. var contact:Contact = new Contact("Dubreuil","Henry","h.dubreuil@free.fr","01.75.34.24.10");
  18. carnet.addContact(contact);
  19.  
  20. assertEquals(1,carnet.count);
  21. }
  22.  
  23. function testInstancied() {
  24. assertNotNull(carnet);
  25. }
  26. }
  27.  

Maintenant que nous disposons d'un test, il suffit de le lancer mais pour cela nous allons créer une classe Application qui s'en chargera. Cette classe n'est qu'un point d'entrée pour lancer les tests dont voici la structure :

  1.  
  2. import buRRRn.ACTUce.TestSuite;
  3.  
  4. class Application {
  5. public static function suite():TestSuite {
  6. var suite:TestSuite = new TestSuite();
  7. suite.addTest( new TestSuite( TestAddressBook ) );
  8. return suite;
  9. }
  10.  
  11. public static function main() {
  12. buRRRn.ACTUce.Application.run( suite() );
  13. }
  14. }
  15.  

Cette classe possède une méthode statique suite qui construit une TestSuite contenant les suites de toute les classes tests à executer. Cette suite de tests est passée au framework ACTUce pour les executer.

Pour conclure, les tests unitaires sont des outils puissant permettant une autre approche de la programmation en divisant le travail en petits problèmes qui peut être résolu par étapes. Le fait de poser le probleme avant de coder sa solution permet de mieux réfléchir sur sa résolution.

Ils ont surtout un avantage considérable sur le remaniement de votre application en évitant une régression de votre code si vous y apportez une modification. Les erreurs corrigés ne pourront plus se produire puisqu'elles seront validées par un test.

Les tests unitaires n'empêcheront pas les erreurs puisque nous sommes des êtres humains et non des machines mais ils vous permettront d'avoir des applications ayant très peu d'erreurs.

Pour utiliser ASTUce vous devez d'abord installer Core2 que vous pouvez télécharger ici sous la forme d'une extension pour Flash : Core2.mxp

Vous trouverez ici aussi un gabarit de projet flash incluant ASTUce : Template.zip

Pour en savoir plus sur Core2 voir : La librairie Core2.

Par ITERATIF - BUGALOTTO Olivier (2006)


    Commenter




      WORKS

    • Travaux

      PRODUCTS

    • ZenBook
    • E-ZEN Galery
    • FlashConf
    • EXOA MP3-Player

      SERVICES

    • Application Facebook
    • Advergame
    • Site Web
    • Référencement
    • Hébergement
    • Graphisme
    • Bannières & Animations
    • Application Flash

      EXOA

    • Contact
    • A propos
    • CGV
    • Mentions Légales

    © 2012 exoa labs, SIRET :517 668 349 00015 · Tél : 06.25.59.18.68 · contact@exoa.fr