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

Pièges et difficultés du BDD : comment les résoudre ?

Pièges et difficultés du BDD : comment les résoudre ?

Marie-Laure Thuret

April 23, 2015
Tweet

More Decks by Marie-Laure Thuret

Other Decks in Programming

Transcript

  1. Pièges et difficultés du BDD :
    comment les résoudre ?

    View Slide

  2. Rodolphe Bung

    @gnubdor
    Marie-Laure Thuret

    @mlthuret
    Développeurs chez

    View Slide

  3. Qui pratique le BDD ?

    View Slide

  4. View Slide

  5. Celui qui aime Word
    ou lorsque le métier n’a pas envie de changer ses pratiques

    View Slide

  6. Le métier rédige ses propres
    spécifications
    en doublon
    avec les scénarios BDD présents dans
    la base de code

    View Slide

  7. Faciliter l’accès
    aux scénarios BDD

    View Slide

  8. View Slide

  9. Faire rédiger les scénarios
    par les développeurs
    en collaboration
    avec le métier

    View Slide

  10. Celui qui reste dans sa bulle
    ou lorsque le développeur rédige seul les scénarios

    View Slide

  11. Le développeur élabore le
    scénario seul, sans se
    soucier de l’avis du
    métier

    View Slide

  12. Faire systématiquement
    valider les scénarios
    par le métier

    View Slide

  13. Ne pas négliger l’aspect de la
    documentation
    vivante
    pour favoriser l’adoption

    View Slide

  14. View Slide

  15. View Slide

  16. Celui qui se perd dans les détails
    ou lorsque la lisibilité devient pénible

    View Slide

  17. Des détails sont présents
    dans le scénario même s’ils
    n’ont
    pas d’impact direct
    avec le comportement
    exprimé

    View Slide

  18. Feature: Booking a trade
    Scenario: when a transaction is made by a customer, it needs to be
    booked after being executed
    Given a customer has made a quote request for 2 tons of AH
    And the trader replied with an ask price at 35 and a bid price at 45
    When the customer buys 2 tons of AH
    Then the trade should be booked

    View Slide

  19. Le scénario exprime
    la totalité
    des cas possibles

    View Slide

  20. Feature: Buying actions
    Scenario Outline: a customer buys actions at the trader ask price
    Given a customer requested to buy « » actions of « »
    When the trader ask for « » per action
    Then the customer should pay « »
    Examples:
    | number-of-actions | action-name | trader-ask | total-amount |
    | 10 | Bioware | 30 | 300 |
    | 10 | Rockstar | 100 | 1000 |
    | 5 | Quantic Dreams | 25 | 125 |
    | 100 | Telltales | 10 | 1000 |
    | 10000 | Naughty dogs | 70 | 700000 |
    | 10 | Electronic Arts | 2 | 20 |

    View Slide

  21. N’exprimer que les cas les
    plus représentatifs

    View Slide

  22. Feature: Buying actions
    Scenario: a customer buys actions at the trader ask price
    Given a customer has requested to buy "10" actions in euros of "Rockstar"
    When the trader ask for "30" euros each
    Then the customer should pay "300" euros

    View Slide

  23. N’ajouter une donnée précise
    que si elle est
    utiles aux assertions
    du scénario

    View Slide

  24. Favoriser une
    expression déclarative
    dans les scénarios

    View Slide

  25. Feature: Booking a trade
    Scenario: when a transaction is made by a customer, it needs to be booked
    after being executed
    Given the customer has received prices
    When the customer sends an execution request
    Then the transaction should be booked

    View Slide

  26. Feature: Buying actions
    Scenario: a customer buys actions at the trader ask price
    Given a customer has requested to buy "10" actions in euros.
    When the trader ask for "30" euros each
    Then the customer should pay "10 * 30" euros, i.e. "300" euros

    View Slide

  27. Celui qui maitrise le
    copié/collé
    ou lorsque les scénarios sont massivement dupliqués

    View Slide

  28. Un pattern unique
    se dégage de l’ensemble des
    scénarios

    View Slide

  29. Eliminer les détails
    superflus

    View Slide

  30. Se poser la question de la
    nécessité du scénario
    s’il ressemble trop à un autre

    View Slide

  31. Ne pas prendre l’écriture des
    scénarios à la légère : ils
    garantissent les features
    implémentées par le système

    View Slide

  32. Celui qui mange trop de glace
    ou lorsque l’ensemble des scénarios est end-to-end

    View Slide

  33. Tous les scénarios sont écrits de
    manière à exercer le
    système de bout en bout

    View Slide

  34. Feature: Booking a trade
    Scenario: when a transaction is made by a customer, it needs to be booked
    with pricing information
    Given the customer has sent a quote request
    And the trader price is :
    | ask | 15 |
    | bid | 10 |
    When the customer execute the quote with the way ‘Buy’
    Then the booking request should have a :
    | client price | 15 |
    | trader bid | 10 |
    | trader ask | 15 |

    View Slide

  35. View Slide

  36. A chaque ajout/modification d’une
    fonctionnalité
    tous les scénarios BDD
    sont KO

    View Slide

  37. Les scénarios sont
    lents à s’exécuter

    View Slide

  38. Ecrire des scénarios avec
    différents niveaux de
    granularité
    en fonction du comportement que l’on
    souhaite exprimer

    View Slide

  39. View Slide

  40. View Slide

  41. View Slide

  42. Celui qui en perd son latin
    ou l’incapacité à faire émerger un ubiquitous language

    View Slide

  43. Les scénarios utilisent
    des synonymes
    pour décrire les mêmes concepts

    View Slide

  44. Le vocabulaire utilisé dans les
    scénarios
    ne reflète pas
    celui qu’utilise l’équipe

    View Slide

  45. Provoquer les conversations et
    relever les mots
    qui émergent

    View Slide

  46. Monter des points réguliers
    pour partager les concepts métiers
    et se mettre d’accord sur l’emploi
    des mots à utiliser

    View Slide

  47. Tenir un glossaire
    des mots à utiliser, ainsi que ceux
    que l’on aurait volontairement mis
    de côté

    View Slide

  48. S’imposer de la
    rigueur

    View Slide

  49. Créer ses
    propres concepts
    et ne pas dépendre d’acteurs
    externes

    View Slide

  50. Celui qui n’est pas soigneux
    ou lorsque le code des fixtures devient pénible à maintenir

    View Slide

  51. Le moindre changement dans le
    code des fixtures entraine une
    série de régressions

    View Slide

  52. Prendre soin
    de son code de tests

    View Slide

  53. Revoir l’implémentation
    des fixtures si elles ne sont pas
    écrites en paire

    View Slide

  54. Celui qui veut imiter Mac Gyver
    ou lorsque le développeur décide de privilégier l’outillage à la
    lisibilité des scénarios

    View Slide

  55. Les scénarios sont
    illisibles
    car voulant tirer au maximum
    parti des possibilités liées à
    l’outil BDD utilisé

    View Slide

  56. Feature: As the customer, I want to be able to send a request for a price to a pricer so I can get a price
    Scenario: Customer sends a price request and the pricer receive it
    Given a request for a price defined by "generic_price_request.json"
    When the customer sends the request defined by:
    | REQUEST_ID | CLIENT_ID | PRODUCT_INFO | TIMESTAMP | STATUS_CODE | STATUS_TEXT | TEXT |
    | 110e8400-e29b-11d4-a716-446655440000 | 42 | X_EUR_BMW_537389873 | 1422207807 | | | |
    Then the pricer should receive a request defined by:
    | REQUEST_ID | CLIENT_ID | PRODUCT_INFO | TIMESTAMP | STATUS_CODE | STATUS_TEXT | TEXT |
    | 110e8400-e29b-11d4-a716-446655440000 | 42 | X_EUR_BMW_537389873 | 1422207807 | | | |
    Scenario: Pricer sends a acknowledgment of the price request to the customer
    Given the pricer received a price request defined by:
    | REQUEST_ID | CLIENT_ID | PRODUCT_INFO | TIMESTAMP | STATUS_CODE | STATUS_TEXT | TEXT |
    | 110e8400-e29b-11d4-a716-446655440000 | 42 | X_EUR_BMW_537389873 | 1422207807 | | | |
    When the pricer sends an acknowledgement defined by:
    | MESSAGE_ID | REQUEST_ID | TIMESTAMP | STATUS_CODE | STATUS_TEXT | TEXT | PRICE |
    | 1124d9e8-6266-4bcf-8035-37a02ba75c69 | 110e8400-e29b-11d4-a716-446655440000 | 1422219048 | 1 | ACCEPTED | | |
    Then the customer should receive a acknowledgement defined by:
    | MESSAGE_ID | REQUEST_ID | TIMESTAMP | STATUS_CODE | STATUS_TEXT | TEXT | PRICE |
    | 1124d9e8-6266-4bcf-8035-37a02ba75c69 | 110e8400-e29b-11d4-a716-446655440000 | 1422219048 | 1 | ACCEPTED | | |
    Scenario: Pricer sends a price to the customer
    Given the pricer sent an acknowledgement defined by:
    | MESSAGE_ID | REQUEST_ID | TIMESTAMP | STATUS_CODE | STATUS_TEXT | TEXT | PRICE |
    | 1124d9e8-6266-4bcf-8035-37a02ba75c69 | 110e8400-e29b-11d4-a716-446655440000 | 1422219048 | 1 | ACCEPTED | | |
    When the pricer sent a price defined by:
    | MESSAGE_ID | REQUEST_ID | TIMESTAMP | STATUS_CODE | STATUS_TEXT | TEXT | PRICE |
    | ac56a704-260b-45f5-85ac-e1b451bb79bc | 110e8400-e29b-11d4-a716-446655440000 | 1422219048 | 1 | UPDATED | | 555 |
    Then the customer should receive the price defined by:
    | MESSAGE_ID | REQUEST_ID | TIMESTAMP | STATUS_CODE | STATUS_TEXT | TEXT | PRICE |
    | ac56a704-260b-45f5-85ac-e1b451bb79bc | 110e8400-e29b-11d4-a716-446655440000 | 1422219048 | 1 | UPDATED | | 555 |

    View Slide

  57. Le code des fixtures est
    trop sophistiqué

    View Slide

  58. toujours privilégier
    la compréhension
    du scénario sur la technique

    View Slide

  59. Feature: Price request mapping for the pricer
    Scenario: A customer price request is converted in order to be understood by the pricer
    Given a request for a price from the customer containing the following information :
    | Request Id | 1 |
    | Customer Id | 42 |
    | Product Type | Actions |
    When the request is converted
    Then the pricer request should contains the following information :
    | Request Id | 1 |
    | Customer Id | 42 |
    | Product Type | A |

    View Slide

  60. Celui qui met du concombre à
    toutes les sauces
    ou lorsqu’on oublie que tout ne se prête pas au BDD

    View Slide

  61. Des tests
    purement techniques
    sont exprimés en gherkin

    View Slide

  62. Feature: System restart behavior
    Scenario: As the system, I want all my transactions to be closed when I restart
    Given a system with 8 opened transactions
    When the system restarts
    Then no transactions should be opened

    View Slide

  63. Identifier la cible du
    scénario
    Sera-t-il compris par le métier ?

    View Slide

  64. Converser, communiquer, collaborer !
    Faire émerger l’ubiquitous language

    Mieux se comprendre et lever les ambiguïtés

    Faire attention à la rédaction des scénarios
    lisible

    compréhensible

    déclaratif

    Ne pas négliger le code des fixtures
    même standards que le code de production

    facile à maintenir

    View Slide

  65. QUestions ?

    View Slide