Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

1.9k

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.).

Félix-Antoine Bourbonnais

November 07, 2017
Tweet

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
    [email protected]
    conferences.elapsetech.com
    Toutes nos présentations
    conferences.elapsetech.com
    /atdd-double-boucle
    Diapositives et références
    Pascal Roy
    @

    View Slide