"Spécification par l'exemple" par l'exemple : le BDD démystifié

Notes de l'éditeur

• #4: Qui suis je : développeur décomplexé ayant eu des expériences diverses avec le BDD (échecs et succès) But: donner envie d'essayer ou de réessayer le BDD Spécification par l'exemple par l'exemple Retirer la magie Trucs et astuces issu de la pratique Pour ceux qui l'on pratiquer : une approche différente
• #5: L'expression des besoins est difficile : Des éléments sous entendu peuvent être oublié lors du développement Des cas d'erreur ou cas limites peuvent être géré que lors du développement Sans cas précis, l'interprétation du besoin exprimé peut divergé du besoin réel La boucle de rétro action est trop longue entre l'expression du besoin et la démonstration du produit
• #6: Lors que les tests fonctionnels sont écrit après : Ne sont pas exhaustifs Sont difficiles à écrire Peuvent clignoter s'ils sont basés sur les données vivantes
• #7: Documentation fonctionnelle : peu de confiance Dans un cycle itératif de développement la documentation suit difficilement l'état réel du produit. On ne peut jamais savoir si la documentation est juste, même si elle l'est.
• #55: Spécification par l'exemple collaboration étroite DEV / PO est nécessaire utiliser des exemples permet d'ouvrir la discussion et de trouver de nombreux cas permet une boucle de rétroaction très rapide définition au plus tôt de toutes les entrées sorties nécessaires une User Story est déclinée en nombreux scénarios les phrases exécutables sont réutilisables découper les scénarios garder uniquement le nécessaire garder en tête la lisibilité les données non nécessaires à la lisibilité peuvent être définies dans le code de test ne pas hésiter à dérouler l'algorithme à partir des exemples du scénario envisager différents cas : cas nominal, cas limite, cas d'erreur organiser les scénarios : niveau d'abstraction, différents cas Tests fonctionnels le développeur est guidé, le code est tiré par les tests on écrit uniquement le code nécessaire ni plus ni moins tests exhaustifs le code doit être flexible pour mocker les interactions extérieures une boucle BDD induit plusieurs boucles TDD tests stables : les interactions extérieures sont mockées Documentation exécutable issue du code, la documentation est à jour toujours les niveaux d'abstraction permettent d'inclure une documentation adaptée au contexte de la documentation projet