ATDD à double boucle: automatiser un test d'acceptation (ATQC17 - 90 minutes)

/ Édition 90 minutes

Imaginez que vous adoptez le BDD et avez des scénarios Gherkin à automatiser… Vous ne savez pas trop comment vous y prendre et ça fait beaucoup de tests bout-en-bout difficiles à maintenir...

Comment faire techniquement pour partir du scénario et l'automatiser?
Comment éviter d'écrire uniquement des tests bout-en-bout?
Comment faire cohabiter tout cela avec les tests unitaires?

Cette présentation montre à l'aide d'une démonstration technique de l'ATDD (avec Cucumber-JVM) comment faire pour d'abord écrire un test "petit" couvrant la logique d'affaires, puis écrire une deuxième implémentation du test pour couvrir le UI et l'infrastructure. Le tout en respectant la pyramide des tests!

Vous apprendrez comment faire cohabiter plusieurs implémentations du code de test ("glue / step definitions") pour un même scénario que votre intégration continue pourra filtrer et configurer dans un "pipeline".

Présentation technique (Java et Cucumber) et de niveau avancé. Le participant doit savoir au minimum utiliser un outil de test unitaire et connaître ce qu'est un test d'acceptation automatisé (ex.: Cucumber, SpecFlow, etc.).

Transcript

1. FÉLIX-ANTOINE BOURBONNAIS
   B.ING., M.SC, PSM
   Agile Tour Québec 2017
   ATDD à double boucle
   automatiser un test d'acceptation
   

   View Slide

2. Diapositives, références et vidéos
   http://conferences.elapsetech.com/atdd-double-boucle
   Cette présentation s’adresse à un public
   avancé et très technique.
   

   View Slide

3. • Comprendre le cycle de l’ATDD
   • Comprendre comment piloter le développement à partir d’une User Story.
   • Comprendre le lien entre le TDD et l’ATDD
   • Savoir comment exécuter des scénarios à différents niveaux
   • Avoir un aperçu de comment enchaîner (pipeline) les tests
   Objectifs
   

   View Slide

4. View Slide

5. Qu’est-ce qu’un test d’acceptation
   ou une Story Test ?
   

   View Slide

6. Est-ce que je produis
   la bonne chose?
   (Building the right thing)
   8
   

   View Slide

7. Specification by Example
   Tests de Story
   Tests unitaires (type)
   Tests d’API
   Tests développeurs
   Tests de composantes
   Types de tests
   Les types de tests…
   Tiré du livre More Agile Testing
   Orienté AFFAIRES
   Orienté TECHNOLOGIE
   Guide le DÉVELOPPEMENT
   Guide le DÉVELOPPEMENT
   Critique le PRODUIT
   ATDD
   TDD
   

   View Slide

8. View Slide

9. Tests d’acceptation/Story Tests
   !=
   Tests bout-en-bout
   

   View Slide

10. La portée (scope) d’un test est la distance
    entre le point d’appel et de validation
    

    View Slide

11. Un type de test (ex.: Feature/Story)
    n’est pas directement relié à
    une portée (ex.: bout-en-bout).
    

    View Slide

12. Image par Gamma-Ray Productions sur Flickr
    Attention en automatisant !
    % du portfolio
    de tests auto.
    (tous les types)
    Large (L)
    Moyen (M)
    Petit (S)
    ~10%
    ~20%
    ~70%
    Bout-en-bout
    Toutes composantes
    Une ou quelques classes
    Une composante
    intégrée
    Fragilité des tests
    

    View Slide

13. View Slide

14. « Feature File »
    

    View Slide

15. Le Gherkin
    

    View Slide

16. Gherkin != BDD
    

    View Slide

17. Le BDD est une méthode axée sur la
    collaboration pour comprendre et spécifier les
    besoins d’affaires
    

    View Slide

18. View Slide

19. • Cucumber et sa famille
    • SpecFlow
    Les outils en bref
    

    View Slide

20. • Feature File
    • Step Definitions / Glues
    • Support Classes (à venir)
    Anatomie de Cucumber
    

    View Slide

21. View Slide

22. ATDD:
    Acceptance* Test Driven Development
    * Ne pas confondre avec les tests d’acceptation utilisateur. Acceptation ici = test des
    critères d’acceptation de la Story.
    

    View Slide

23. Le but de l’ATDD est de piloter le
    développement du système
    

    View Slide

24. Notre but est de nous assurer de répondre aux
    critères de la User Story et la considérer
    comme terminée.
    

    View Slide

25. ATDD
    1
    Écrire un
    scénario qui
    échoue
    2
    Scénario
    passe
    3
    

    View Slide

26. • Java
    • Cucumber-JVM
    • Junit
    • Eclipse (IDE)
    • Maven
    Outils utilisés pour la démonstration
    

    View Slide

27. Démonstration
    Vidéo de la démonstration
    http://conferences.elapsetech.com/atdd-double-boucle
    

    View Slide

28. View Slide

29. Constat: nous n’avons pas codé le UI et tous
    les tests passent !?!
    

    View Slide

30. La solution n’est pas de choisir la portée de
    chaque scénario.
    

    View Slide

31. ATDD à double boucle
    * Uniquement certains scénarios (voir Pyramide des tests). Pourrait être @MEDIUM ou autre portée…
    Logique
    (domaine)
    UI
    Infra /
    Données
    2
    c
    Scénario A
    @LARGE*
    2
    a
    2
    b
    Scénario A
    @SMALL
    1
    c
    1
    a
    1
    b
    

    View Slide

32. @scope=web
    Scenario: Transfering money adjusts the account balances
    Given an account 111 with 1000$ in it
    And an account 222 with 500$ in it
    When I create a transaction of 100$ from 111 to 222
    Then the account 111 has 900$ in it
    And the account 222 has 600$ in it
    @scope=web
    Scenario: Transfering money creates an accepted transaction log
    Given an account 333 with 1000$ in it
    And an account 444 with 500$ in it
    When I transfer 100$ from 333 to 444
    Then a transaction log is created for the amount of 100$
    Scenario: Transfering money when the account doesn't have the funds
    Given an account 555 with 99$ in it
    And an account 666 with 500$ in it
    When I transfer 100$ from 555 to 666
    Then a transaction log shows that the transfer was refused
    Exemple
    1
    2
    1
    2
    1
    

    View Slide

33. Démonstration
    Vidéo de la démonstration
    http://conferences.elapsetech.com/atdd-double-boucle
    

    View Slide

34. View Slide

35. Étape 1
    • Nous avons écrit 1 Story Test pour nous assurer du comportement tel que
    spécifié dans la User Story.
    • Nous avons piloté l’écriture de la logique d’affaires pour faire passer le
    premier scénario.
    • Nous avons écrit des tests unitaires en TDD pour nous assurer de couvrir
    et bien construire le code de production.
    Résumé
    

    View Slide

36. Étape 2
    • Nous avons branché le même scénario à une portée plus grande afin de
    piloter le développement de l’API (UI)
    Résumé
    

    View Slide

37. Étapes suivantes
    • Implémenter les autres scénarios avec la même boucle
    • Par contre, ces scénarios ne requièrent pas d’être pilotés à une portée
    plus grande que AppService+FakeDB.
    Résumé
    

    View Slide

38. Pourquoi ?
    

    View Slide

39. merci .
    

    View Slide

40. Site
    elapsetech.com
    Twitter
    @fbourbonnais
    Courriel
    fbourbonnais@elapsetech.com
    conferences.elapsetech.com
    Toutes nos présentations
    conferences.elapsetech.com
    /atdd-double-boucle
    Diapositives et références
    Pascal Roy
    @
    

    View Slide