ATDD — Acceptance Test-Driven Development¶

Définir les tests d'acceptation avant le développement — la collaboration trilaterale PO/Dev/QA.

Le principe¶

ATDD place le test d'acceptation au centre du processus de développement. Avant d'écrire une seule ligne de code, l'équipe définit ensemble les critères qui prouveront que la fonctionnalité est terminee.

graph LR
    A["Definir les tests<br/>d'acceptation"] --> B["Developper"]
    B --> C["Executer les tests"]
    C -->|"echouent"| B
    C -->|"passent"| D["Feature terminee"]

Différence avec BDD¶

La collaboration trilaterale¶

graph TD
    PO["Product Owner<br/>Definit les criteres metier"] 
    DEV["Developpeur<br/>Identifie les contraintes techniques"]
    QA["QA<br/>Trouve les cas limites et les risques"]

    PO --- TA["Tests d'acceptation"]
    DEV --- TA
    QA --- TA

Le rôle de chacun¶

Le processus¶

1. Atelier de définition : avant le sprint, l'équipe se reunit pour chaque user story
2. Rédaction des tests : écrire les tests d'acceptation sous forme de tableaux ou de scenarios
3. Développement : le développeur code en visant les tests d'acceptation
4. Vérification : les tests d'acceptation sont exécutés — automatiquement ou manuellement
5. Validation : le PO confirme que les critères sont remplis

Format des tests d'acceptation¶

Tableaux décision¶

Feature : Calcul de remise

| Montant panier | Client fidele | Remise attendue |
| -------------- | ------------- | --------------- |
| < 50€          | Non           | 0%              |
| < 50€          | Oui           | 5%              |
| >= 50€         | Non           | 10%             |
| >= 50€         | Oui           | 15%             |

Critères textuels¶

Feature : Inscription utilisateur

Criteres d'acceptation :
- [ ] L'utilisateur peut s'inscrire avec email + mot de passe
- [ ] Le mot de passe doit contenir au moins 8 caracteres, 1 majuscule, 1 chiffre
- [ ] Un email de confirmation est envoye dans les 30 secondes
- [ ] Un compte en doublon affiche "Cet email est deja utilise"
- [ ] L'utilisateur ne peut pas se connecter tant que l'email n'est pas confirme

Scenarios Gherkin¶

Les tests d'acceptation ATDD peuvent aussi être écrits en Gherkin (convergence avec BDD) :

Feature: Calcul de remise

  Scenario: Client fidele avec panier >= 50€
    Given un client marque comme "fidele"
    And un panier de 75€
    When le systeme calcule la remise
    Then la remise appliquee est de 15%

Automatisation¶

Avec Robot Framework¶

Robot Framework est particulièrement adapté a ATDD grâce à son format tabulaire lisible par les non-techniques :

*** Settings ***
Library    Browser

*** Test Cases ***
Client fidele avec gros panier obtient 15% de remise
    [Documentation]    Critere d'acceptation : remise 15% pour fideles >= 50€
    Given un client fidele connecte
    And un panier de 75 euros
    When le systeme calcule la remise
    Then la remise affichee est 15 pourcent

*** Keywords ***
un client fidele connecte
    New Browser    chromium    headless=true
    New Page       ${BASE_URL}/login
    Fill Text      id=email    fidele@example.com
    Fill Text      id=password    P@ssw0rd!
    Click          id=submit

Avec FitNesse¶

FitNesse utilise des tableaux wiki editables par le PO :

| Calcul Remise                          |
| montant | client fidele | remise?      |
| 30      | false         | 0            |
| 30      | true          | 5            |
| 75      | false         | 10           |
| 75      | true          | 15           |

Le développeur implémenté une "fixture" qui connecte le tableau au code :

public class CalculRemise {
    private int montant;
    private boolean clientFidele;

    public void setMontant(int montant) { this.montant = montant; }
    public void setClientFidele(boolean fidele) { this.clientFidele = fidele; }

    public int remise() {
        if (montant >= 50 && clientFidele) return 15;
        if (montant >= 50) return 10;
        if (clientFidele) return 5;
        return 0;
    }
}

ATDD dans le cycle de vie¶

graph LR
    US["User Story"] --> AT["Atelier ATDD<br/>Criteres d'acceptation"]
    AT --> TDD["TDD<br/>Implementation"]
    TDD --> BDD["BDD<br/>Scenarios"]
    BDD --> ACC["Tests d'acceptation<br/>passes ?"]
    ACC -->|"oui"| DONE["Done"]
    ACC -->|"non"| TDD

ATDD encadre le développement de bout en bout :

1. Les tests d'acceptation définissent le "done"
2. BDD détaillé les scenarios de comportement
3. TDD guide l'implémentation technique
4. Les tests d'acceptation valident la fin

Outils¶