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 ?

Ecc18b2555b03f1a88d532705ec51dfa?s=128

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 ?

  2. Rodolphe Bung @gnubdor Marie-Laure Thuret @mlthuret Développeurs chez

  3. Qui pratique le BDD ?

  4. None
  5. Celui qui aime Word ou lorsque le métier n’a pas

    envie de changer ses pratiques
  6. Le métier rédige ses propres spécifications en doublon avec les

    scénarios BDD présents dans la base de code
  7. Faciliter l’accès aux scénarios BDD

  8. None
  9. Faire rédiger les scénarios par les développeurs en collaboration avec

    le métier
  10. Celui qui reste dans sa bulle ou lorsque le développeur

    rédige seul les scénarios
  11. Le développeur élabore le scénario seul, sans se soucier de

    l’avis du métier
  12. Faire systématiquement valider les scénarios par le métier

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

    l’adoption
  14. None
  15. None
  16. Celui qui se perd dans les détails ou lorsque la

    lisibilité devient pénible
  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é
  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
  19. Le scénario exprime la totalité des cas possibles

  20. Feature: Buying actions Scenario Outline: a customer buys actions at

    the trader ask price Given a customer requested to buy « <number-of-actions> » actions of « <action-name> » When the trader ask for « <trader-ask> » per action Then the customer should pay « <total-amount> » 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 |
  21. N’exprimer que les cas les plus représentatifs

  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
  23. N’ajouter une donnée précise que si elle est utiles aux

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

  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
  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
  27. Celui qui maitrise le copié/collé ou lorsque les scénarios sont

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

  29. Eliminer les détails superflus

  30. Se poser la question de la nécessité du scénario s’il

    ressemble trop à un autre
  31. Ne pas prendre l’écriture des scénarios à la légère :

    ils garantissent les features implémentées par le système
  32. Celui qui mange trop de glace ou lorsque l’ensemble des

    scénarios est end-to-end
  33. Tous les scénarios sont écrits de manière à exercer le

    système de bout en bout
  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 |
  35. None
  36. A chaque ajout/modification d’une fonctionnalité tous les scénarios BDD sont

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

  38. Ecrire des scénarios avec différents niveaux de granularité en fonction

    du comportement que l’on souhaite exprimer
  39. None
  40. None
  41. None
  42. Celui qui en perd son latin ou l’incapacité à faire

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

  44. Le vocabulaire utilisé dans les scénarios ne reflète pas celui

    qu’utilise l’équipe
  45. Provoquer les conversations et relever les mots qui émergent

  46. Monter des points réguliers pour partager les concepts métiers et

    se mettre d’accord sur l’emploi des mots à utiliser
  47. Tenir un glossaire des mots à utiliser, ainsi que ceux

    que l’on aurait volontairement mis de côté
  48. S’imposer de la rigueur

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

  50. Celui qui n’est pas soigneux ou lorsque le code des

    fixtures devient pénible à maintenir
  51. Le moindre changement dans le code des fixtures entraine une

    série de régressions
  52. Prendre soin de son code de tests

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

    en paire
  54. Celui qui veut imiter Mac Gyver ou lorsque le développeur

    décide de privilégier l’outillage à la lisibilité des scénarios
  55. Les scénarios sont illisibles car voulant tirer au maximum parti

    des possibilités liées à l’outil BDD utilisé
  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 | <null> | <null> | <null> | 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 | <null> | <null> | <null> | 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 | <null> | <null> | <null> | 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 | <null> | <null> | 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 | <null> | <null> | 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 | <null> | <null> | 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 | <null> | 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 | <null> | 555 |
  57. Le code des fixtures est trop sophistiqué

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

  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 |
  60. Celui qui met du concombre à toutes les sauces ou

    lorsqu’on oublie que tout ne se prête pas au BDD
  61. Des tests purement techniques sont exprimés en gherkin

  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
  63. Identifier la cible du scénario Sera-t-il compris par le métier

    ?
  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
  65. QUestions ?