Development

Documentation/fr_FR/book/1.0/15-Unit-and-Functional-Testing (diff)

You must first sign up to be able to contribute.

Changes from Version 1 of Documentation/fr_FR/book/1.0/15-Unit-and-Functional-Testing

Show
Ignore:
Author:
Damien.Rousseau (IP: 81.56.154.60)
Timestamp:
06/10/07 23:35:56 (10 years ago)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Documentation/fr_FR/book/1.0/15-Unit-and-Functional-Testing

    v0 v1  
     1L'automatisation des tests est l'une des avancés majeur en développement depuis la programmation objet. Ceci prend toute sa dimension lors de la conception d'une application web et est gage de qualité même en présence de nombreuses releases. Symfony propose tout un panel d'outils qui facilite l'automatisation des tests, ce chapître va nous les présenter.[[BR]] 
     2 
     3== Automatiser les Tests == 
     4 
     5 
     6Tout développeur ayant un tant soit peu d'expérience connait les implications en temps d'investissement pour mener à bien ses tests. Ecrire les tests, les exécuter puis en analyser les résultats est un travail pouvant s'avérer laborieux. En outre, les applications web sont en perpetuelles évolutions ce qui conduit bien souvent à des remaniement de code donc à des risques de voir apparaître de nouvelles erreurs. 
     7 
     8C'est pourquoi il est fortement conseillé, voire obligatoire d'utiliser l'automatisation des tests afin d'avoir des conditions de développement optimales. Seul toute une batterie de tests peut garantir qu'une application aura bien le comportement auquel on s'attend. Même si on vient à remanier le code, les tests automatisés préviennent d'une régression accidentelle de l'application. En plus, le développeur est contraint de se plier à des règles d'écriture rigoureuses et standardisées capables d'êtres interprétées par des framework de tests. 
     9 
     10D'autre part, la génération automatique de tests peut parfois remplacer la documentation en illustrant de manière claire ce qu'une application est censée faire. Une série de tests montrant les résultats attendus peut contribuer à la compréhension de la finalité d'une méthode. 
     11 
     12Symfony applique ce principe à lui-même et tout son code est ainsi validé par l'utilisation de l'automatisation des tests. Les tests unitaires et fonctionnels ne sont pas fourni en standard mais peuvent êtres récupérés sur le dépot SVN ou en ligne à l'adresse http://www.symfony-project.com/trac/browser/trunk/test  
     13 
     14 
     15== Test Unitaires et tests Fonctionnels == 
     16 
     17 
     18Les tests unitaires confirment qu'une portion de code fournit bien une sortie correcte en fonction de paramètres d'entrées donnés. Ils valident le fonctionnement de mé ou de fonctions pour les cas particuliers. Les tests unitaires ne traitent qu'un cas à la fois ce qui conduit à les répéter dans le cas ou une méthode réagis différement en fonction de certaines situations. 
     19 
     20Les tests fonctionnels valident un dispositif complet et non pas une simple conversion d'entrés-sorties. Par exemple, un système de cache ne pourra être validé que par un test fonctionnel dans la mesure ou il nécessite plusieurs étapes : la première fois qu'une page est demandée, elle est envoyée au navigateur tandis que la deuxième fois, elle est prise dans cache. Donc, les tests fonctionnels reposent sur des scénarios pour valider un processus. Symfony exige d'écrire des tests fonctionnels pour chaques actions. 
     21 
     22Pour des interactions complexes, ces tests peuvent faire défaut comme par exemple l'utilisation d'AJAX qui nécessite un navigateur avec javascript. Ceci implique l'utilisation d'un outil spécifique non fourni avec le framework. De même, seul un humain est capable de valider des effets visuels. 
     23 
     24Si vous voulez une approche complète des tests automatisés, vous aurez probablement besoin d'une combinaison de ces trois méthodes. De toutes les fa�ons, ayez comme directive de vous imposer des tests simples et lisibles. 
     25 
     26    Les tests automatisés travaillent par comparaison entre résultats et résultats attendus. Autrement dit, ils évaluent les assertions (expressions du genre $a == 2). La valeur d'une assertion est du type true ou false ( vrai ou faux ), ce qui détermine si le test passe ou échoue. On parle du mot "assertion" lorsque l'on utilise un contexte de tests automatisés. 
     27 
     28 
     29== Développement piloté par les tests ( Test-Driven Development : TDD) == 
     30 
     31 
     32Dans une approche méthodologique basé sur TDD, les tests sont écrit avant le code. Ceci va vous aider à vous concentrer sur sur ce que la fonction doit accomplir avant d'écrire son code. C'est une bonne méthode, à l'instar d'autres, telle que le développement agile ( Extreme Programming : XP ), pourtant elles aussi recommandées. Mais ce qui abondera en son sens est le fait ind�niable que si vous n'écrivez pas les tests en premiers, vous ne les écrirez jamais. 
     33 
     34Un exemple, imaginons que vous vouliez développez une fonction permettant de nettoyer une chaîne de caratères. Cette fonction enlève les espaces de début et de fin, remplace les caratères non alphabétique par le caractère souligné ( _ ) et convertit les majuscules en miniscules. Dans le cas d'un développement TDD, vous devrez réfléchir à toutes les situations possibles et fournir des exemples d'entrées avec leurs sorties respective, comme illustré dans le tableau 15-1.