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

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