Méthodologies, XP Programming, TDD

Thématiques abordées

• Comment aborder les tests ?
• La pratique du test en XP Programming
• L'approche TDD
• L'approche ATDD / BDD
• Une approche pragmatique

---

Il existe de nombreuses types de méthodologie pour construire une couverture de tests efficace.

• L'approche analytique
• L'approche basée sur les modèles
• L'approche consultative
• L'approche méthodique
• L'approche dynamique ou par heuristique
• L'approche par respects de standards
• L'approche Top-Down
• L'approche Bottom-Up
• L'approche TDD
• L'approche ATDD/BDD

Il y a plusieurs débats existentiels dans la mise en place des tests

Devons-nous écrire les tests avant de coder ?

Est-ce qu'il faut obtenir 100% de couverture de code ?

Quels types de tests sont les plus efficaces ?

Pourquoi mes tests "cassent" ?

Quand dois-je m'arrêter de tester ?

---

La méthodologie XP

Méthodologie de développement popularisé par Kent Beck dans "Extreme Programming Explained"

Anecdocte amusante : le projet développé a été abandonné un an après.

Le projet Mercury a utilisé cette approche pour une partie des logiciels.

Tester tout de suite

Plus vous attendez , moins vous vous rappelerez les modifications qui ont amené au bug.

Teste ce que tu veux qui fonctionne

Les tests doivent être répétables

Les tests doivent être automatisés

Les tests sont la seule documentation

Les tests d'acceptations sont écrits juste après la story

Les entrées / sorties sont fournies par le client sous la forme d'Excel

Tester un peu, coder un peu

Impact sur le codage de la fonctionnalité

• Exprimer toutes les idées de la story mais pas plus
• Pas de code dupliqué
• Avoir le minimum de classes et de méthodes

---

L'approche TDD

Cela ne veut pas dire :

Type, Deliver, Debug

Test Driven design

A l'origine, c'était une pratique dite de test first.

Les pré-requis

• Tout code fonctionnel doit avoir un test avant sa propre existence
• Chaque feature ET bug fix ont un test unitaire et un test d'acceptance
• Chaque développeur sait écrire un test unitaire
• Chaque équipe de développement adopte un framework de tests

• Je nécessite rarement d'appeler le support ou les BA et cela ne termine pas en longue session de débogage.
• Je me sens confiant dans la qualité de mon travail.
• J'ai plus de temps pour développer comme professionel.

---

L'approche ATDD / BDD

Acceptance TDD

Behavior Driven Design

Cette pratique a pour objectif d'aider les projets logiciels à fournir exactement ce que le client souhaite.

Le client est impliqué dans l'écriture de tests qui servent également de spécifications

Les tests sont écrits en même temps que les user stories.

Exemple de user story

Fonctionnalité : un client existant doit pouvoir se connecter 
à son compte utilisateur avec ses données d’accès

Test d'acceptation

	Scénario : le client saisit les données d’accès correctes 
    lors de la procédure de connexion
    
    Étant donné que j’ai un compte utilisateur valide
    Et que je me trouve sur la page de connexion du site Web
    Quand j’entre mon adresse e-mail dans le champ prévu à cet effet
    Et que j’entre mon mot de passe dans le champ prévu à cet effet
    Et que je clique sur le bouton de connexion
    Alors je devrais être automatiquement connecté

Qu'est ce qu'un test d'acceptation ?

• C'est la propriété du client
• Ils sont écrits conjointement entre le client, le développeur et le testeur
• Les tests sont orientés sur le quoi pas le comment
• Les test sont écrits dans un langage compréhensible du client (langage métier)
• Les test sont concis, précis et non ambigus.

Exemple de mauvais test d'acceptation

  Scenario: L'assuré doit être agé de plus de 18 ans
    Quand je navigue sur "http://www.insuranceadress.com/insurance"
    Et que j'entre "01/01/2001" dans le champ 
      input ayant l'ID "birthdate"
    Quand je clique sur l'élément ayant l'id "suivant"
    Alors je devrais voir un message "L'assuré doit être 
      agé de plus de 18 ans"
    Et le titre de la page HTML doit être "
      S'il vous plaît entrez une nouvelle date de naissance"

Comment rédiger le test ?

L'approche Given/WhenThen

Approche structurée pour écrire des tests. Certains frameworks ont directement repris cette syntaxe comme Cucumber.

• Given : Etant donné. Spécifie une fixture, un état de départ du test.
• When : Quand. Définit une action à réaliser lors du test
• Then : Alors. Conséquence du test, assertion à vérifier
• And : Et. enchainement d'assertions à vérifier

Comment améliorer le test ?

• Ne pas faire le lien entre le test et l'IHM
• Ne pas faire de tests trop verbeux
• Ne pas tester des fonctionnalités triviales
• Eviter toute dépendance entre les tests
• Considérer que le test part d'un état initial connu.
• Soyez court et lisible
• Décrivez un résultat ou un comportement.
• Identifiez clairement les entrées et les sorties du test

Quel rapport avec JUNIT ?

Les tests d'acceptation peuvent être écrits directement avec JUnit ou en utilisant un framework additionel