« Introduction au test logiciel/Intégration dans le processus de développement » : différence entre les versions
Contenu supprimé Contenu ajouté
remaniement et complétion |
|||
Ligne 59 :
== Le développement piloté par les tests ==
Le [[w:Test Driven Development|développement piloté par les tests]] (ou « [[w:en:Test Driven Development|Test-Driven Development]] » ou « TTD ») est une pratique souvent utilisée dans les méthodes agiles (on trouve son origine dans l'[[w:Extreme programming|extreme programming]]). Elle consiste à développer l'application selon le cycle suivant :
<div style="border: solid 4px #ddd; font-size: 1.1em; width: 50%; margin-left: auto; margin-right: auto; padding: 10px;">
# Écrire les tests
# Vérifier que ceux-ci ne passent pas
# Écrire le code manquant
# Vérifier que le test passe
# Remanier le code
</div>
=== 1. Écrire les tests ===
Dans le développement piloté par les tests, les tests sont écrit avant le code. Il faut donc commencer par écrire un test ou un petit ensemble de tests qui représente les nouvelles fonctionnalités qu'on va implémenter durant le cycle.
Il faut pour cela se baser sur la spécification, les [[w:Cas d'utilisation|cas d'utilisation]] ou les ''[[w:en:User story|user stories]]''. Écrire les tests d'abord permet au développeur de voir vraiment le comportement qui est attendu avant de toucher au code.
=== 2. Vérifier que les nouveaux tests échouent ===
Il est important de lancer les tests pour s'assurer que les autres passent toujours et que les nouveaux tests ne passe pas. Dans le cas contraire, deux possibilités :
* Le test n'est pas bon
* La fonctionnalité est déjà implémentée. Cela peut arriver étant donné qu'un développeur zélé peut, lorsqu'il touche une partie du code, ajouter dans la foulée un petit peu de plus de fonctionnalité que prévu.
Toutefois, si ce dernier cas se présente plusieurs fois, il faut se poser des questions sur la gestion du projet. Les tâches ont-elles bien été réparties ?
=== 3. Écrire le code ===
Il est important d'essayer de n'écrire strictement que le code nécessaire au passage du test, pas plus. Vous pouvez relancer le test écrit à l'étape 1 autant de fois que nécessaire. Peu importe si le code n'est pas élégant pour l'instant tant qu'il permet de passer le test.
=== 4. Vérifier que tous les tests passent ===
C'est le moment de vérifier que tous les tests passent, ceci afin de vérifier qu'avec les modifications faites on a pas créer de régressions dans le code.
=== 5. Remanier le code ===
Enfin, ''[[w:Refactorisation|refactorisez]]'' le code pour améliorer la conception tout en vérifiant que les tests passent toujours.
== Les tests et l'intégration continue ==
| |||