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

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 ?
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
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
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 |
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
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 ?