Cas pratiques BDD

Contexte Une fonctionnalité permet d’ajouter un commentaire sur un article. Le Problème Le scénario actuel ne définit pas le contexte initial : Scenario: Ajouter un commentaire When je saisis un commentaire valide Then le commentaire est affiché Le Given est absent. Contraintes Réécrire le scénario en ajoutant un contexte initial clair. Livrable attendu Un scénario BDD complet et structuré respectant les bonnes pratiques.

Contexte Une fonctionnalité permet à un utilisateur de réinitialiser son mot de passe. Le Problème Le scénario actuel est trop vague : Scenario: Réinitialisation réussie Given un utilisateur existant When il demande une réinitialisation Then ça marche Le résultat attendu n’est pas mesurable. Contraintes Réécrire le Then pour qu’il décrive un résultat observable et vérifiable. Livrable attendu Un scénario BDD précis décrivant l’affichage d’un message ou l’envoi d’un email.

Contexte Une application web permet aux utilisateurs de se connecter via un formulaire. Un scénario BDD a été écrit pour décrire le comportement attendu en cas d’identifiants invalides. Le Problème Le scénario actuel est incohérent avec le comportement métier : Scenario: Connexion avec mot de passe incorrect Given un utilisateur existant avec email "user@test.com" When il saisit "user@test.com" et "wrongpass" Then il est redirigé vers la page d'accueil La redirection ne devrait pas avoir lieu. Contraintes Corriger uniquement le scénario afin qu’il reflète le comportement attendu en cas d’erreur. Livrable attendu Un scénario BDD cohérent décrivant l’affichage d’un message d’erreur sans redirection.

Contexte Un panier calcule automatiquement le total des produits ajoutés. Le Problème Le scénario actuel contient une incohérence : Scenario: Calcul du total Given un panier avec un produit à 10 And un produit à 5 When je consulte le panier Then le total est 20 Le total attendu est incorrect. Contraintes Corriger uniquement le scénario pour qu’il reflète le calcul réel. Livrable attendu Un scénario BDD cohérent avec le comportement métier.

Contexte Une application e-commerce permet d’ajouter un produit au panier. Un scénario BDD décrit ce comportement. Le Problème Le scénario actuel mélange plusieurs actions dans un seul step : Scenario: Ajouter un produit Given un utilisateur connecté When il sélectionne un produit et clique sur ajouter et va au panier Then le panier contient 1 produit Le step When n’est pas atomique. Contraintes Réécrire le scénario en respectant la granularité des étapes. Livrable attendu Un scénario clair et structuré respectant les bonnes pratiques BDD.

Contexte Une fonctionnalité d’inscription permet à un nouvel utilisateur de créer un compte via email et mot de passe. Le Problème Aucun scénario BDD n’a été rédigé pour décrire le comportement attendu. Contraintes Écrire des scénarios couvrant : inscription valide, email déjà utilisé et mot de passe trop court. Utiliser la structure Given When Then. Livrable attendu Un fichier de scénarios BDD simple décrivant clairement les cas principaux de la fonctionnalité.

Contexte Une application permet à un utilisateur connecté de se déconnecter. Le Problème Le comportement attendu n’est pas formalisé en BDD. Contraintes Créer des scénarios couvrant déconnexion réussie et tentative de déconnexion sans session active. Utiliser Given When Then. Livrable attendu Des scénarios BDD clairs décrivant les comportements attendus de la fonctionnalité.

Contexte Un utilisateur peut modifier ses informations personnelles depuis son profil. Le Problème Aucun scénario BDD ne décrit cette fonctionnalité. Contraintes Créer des scénarios couvrant mise à jour valide, email invalide et champ obligatoire manquant. Livrable attendu Un ensemble de scénarios BDD simples utilisant la structure Given When Then.

Contexte Un moteur de recherche permet de filtrer des produits par mot-clé. Le Problème La fonctionnalité existe mais aucun scénario BDD ne décrit son comportement. Contraintes Créer des scénarios couvrant : résultat trouvé, aucun résultat et recherche avec champ vide. Utiliser Given When Then. Livrable attendu Un ensemble de scénarios BDD simples décrivant les comportements attendus.

Contexte Une application permet à un utilisateur de supprimer définitivement son compte. Le Problème Il faut définir le comportement attendu en langage métier. Contraintes Créer des scénarios couvrant suppression confirmée, annulation de suppression et tentative sans authentification. Livrable attendu Des scénarios BDD simples et structurés décrivant les cas principaux.

Contexte Une application met à jour le stock après chaque commande validée. Le Problème Le scénario actuel ne précise pas l’état initial du stock : Scenario: Mise à jour stock When une commande est validée Then le stock diminue L’absence de Given rend le scénario ambigu. Contraintes Réécrire le scénario en décrivant clairement le stock initial et la quantité commandée. Livrable attendu Un scénario BDD structuré et précis sur la gestion du stock.

Contexte Un processus de validation de commande dépend de la disponibilité du stock et de la validité du paiement. Le Problème Le scénario actuel ne distingue pas clairement les préconditions : Scenario: Validation commande Given un client existant When il valide sa commande Then la commande est confirmée Les conditions stock et paiement ne sont pas décrites. Contraintes Réécrire le scénario en explicitant les dépendances nécessaires dans les Given. Livrable attendu Un scénario BDD complet décrivant toutes les préconditions métier.

Contexte Une application e-commerce permet de finaliser une commande via un service de paiement externe. Des scénarios BDD décrivent le comportement attendu. Le Problème Le scénario actuel ne couvre pas correctement l’échec du paiement : Scenario: Paiement refusé Given un panier valide avec un total de 100 When le paiement est refusé par le prestataire Then la commande est créée Le comportement métier impose qu’aucune commande ne soit créée si le paiement échoue. Contraintes Réécrire le scénario pour refléter l’annulation de la commande et l’affichage d’un message d’erreur clair. Livrable attendu Un scénario BDD cohérent décrivant précisément le comportement attendu en cas d’échec paiement.

Contexte Une API interne permet la création d’un client via requête HTTP. Le Problème Le scénario actuel mélange détails techniques et règles métier : Scenario: Création client Given une requête POST sur /api/client When le payload est envoyé Then le code HTTP 200 est retourné Le scénario ne décrit pas la valeur métier créée. Contraintes Réécrire le scénario en mettant l’accent sur le résultat métier plutôt que sur les détails techniques. Livrable attendu Un scénario BDD orienté utilisateur et valeur métier.

Contexte Une application permet d’exporter des données au format CSV. Le Problème Le scénario actuel contient un résultat trop vague : Scenario: Export réussi Given des données existantes When l’utilisateur exporte Then le fichier est correct Le résultat n’est pas vérifiable. Contraintes Réécrire le Then pour qu’il décrive un résultat observable comme la présence d’un fichier avec un nombre précis de lignes. Livrable attendu Un scénario BDD clair et mesurable décrivant le comportement attendu.

Contexte Une plateforme propose des abonnements mensuels avec renouvellement automatique. Le Problème Les règles de renouvellement, d’expiration et d’échec de paiement ne sont pas décrites. Contraintes Créer des scénarios couvrant renouvellement réussi, échec de paiement et expiration après résiliation. Les scénarios doivent refléter le comportement métier observable. Livrable attendu Un ensemble complet de scénarios BDD décrivant le cycle de vie d’un abonnement.

Contexte Un moteur de recherche permet de filtrer des résultats par catégorie, prix et disponibilité. Le Problème Les combinaisons de filtres ne sont pas décrites en BDD. Contraintes Créer des scénarios couvrant : filtre simple, combinaison de deux filtres et combinaison de trois filtres. Vérifier que seuls les résultats correspondant à tous les critères sont affichés. Livrable attendu Une suite de scénarios BDD décrivant les comportements attendus pour les filtres combinés.

Contexte Une plateforme envoie des notifications différées après certaines actions utilisateur. Le Problème Le comportement attendu selon différents délais n’est pas formalisé. Contraintes Créer des scénarios couvrant notification immédiate, notification différée et absence de notification si l’action est annulée. Décrire clairement les événements déclencheurs. Livrable attendu Une suite de scénarios BDD décrivant précisément la logique temporelle attendue.

Contexte Une application interne gère différents rôles : utilisateur, manager et administrateur, chacun ayant des permissions spécifiques. Le Problème La logique d’accès n’est pas formalisée en BDD. Contraintes Créer des scénarios couvrant : accès autorisé pour un administrateur, accès refusé pour un utilisateur simple et héritage de droits pour un manager. Les scénarios doivent être orientés métier et non techniques. Livrable attendu Un ensemble structuré de scénarios Given When Then décrivant les règles d’accès.

Contexte Un système interne requiert une validation par un manager puis par un administrateur avant approbation finale. Le Problème Le workflow n’est pas documenté en BDD. Contraintes Créer des scénarios couvrant approbation complète, rejet au premier niveau et rejet au second niveau. Décrire clairement chaque étape du processus. Livrable attendu Une suite de scénarios Given When Then représentant fidèlement le workflow métier.

Contexte Une application réglementée exige une traçabilité complète des actions sensibles. Le Problème Le scénario actuel est vague : Scenario: Action sensible Given un utilisateur autorisé When il modifie une donnée critique Then l’action est enregistrée Il ne précise pas les éléments d’audit requis. Contraintes Réécrire le scénario pour décrire clairement les informations enregistrées et consultables dans l’historique. Livrable attendu Un scénario BDD précis décrivant la traçabilité métier attendue.

Contexte Une application permet à plusieurs utilisateurs de réserver simultanément une ressource limitée. Le Problème Le scénario actuel ne décrit pas le comportement en cas de concurrence : Scenario: Réservation simultanée Given une ressource avec 1 unité disponible When deux utilisateurs réservent en même temps Then les deux réservations sont confirmées Ce comportement est incorrect. Contraintes Réécrire le scénario pour refléter qu’une seule réservation peut être confirmée et que l’autre reçoit un message d’indisponibilité. Livrable attendu Un scénario BDD décrivant explicitement la règle métier de gestion de concurrence.

Contexte Un système de réservation orchestre trois services : paiement, inventaire et émission de billet. Les scénarios BDD décrivent le comportement global attendu. Le Problème Le scénario actuel ne tient pas compte d’un échec partiel : Scenario: Réservation confirmée Given un utilisateur avec un moyen de paiement valide And un siège disponible When il confirme la réservation Then le billet est émis Il manque la gestion du cas où l’émission échoue après le paiement. Contraintes Réécrire le scénario pour inclure la compensation métier en cas d’échec final, en restant orienté comportement observable. Livrable attendu Un scénario BDD complet décrivant succès et rollback fonctionnel.

Contexte Un service agrège des données provenant de trois fournisseurs externes. Le Problème Le scénario actuel ignore les défaillances partielles : Scenario: Agrégation réussie Given les fournisseurs sont disponibles When une requête est effectuée Then les données consolidées sont retournées Il ne couvre pas le cas où un fournisseur est indisponible. Contraintes Étendre ou corriger le scénario pour inclure la gestion d’erreur partielle avec retour de données disponibles. Livrable attendu Un scénario BDD décrivant précisément la résilience attendue.

Contexte Une API d’agrégation retourne des données consolidées issues de plusieurs sources. Le Problème Le scénario actuel est trop technique : Scenario: Appel API Given une requête GET sur /aggregate When le service A et B répondent Then la réponse JSON contient status 200 Le scénario ne décrit pas la valeur métier produite. Contraintes Réécrire le scénario pour décrire le résultat fonctionnel attendu par l’utilisateur métier plutôt que les détails HTTP. Livrable attendu Un scénario BDD centré sur le comportement métier observable.

Contexte Une plateforme SaaS permet changement de plan en cours de période avec calcul prorata automatique. Le Problème Les règles de prorata et d’ajustement de facturation ne sont pas décrites. Contraintes Créer des scénarios couvrant upgrade en milieu de période, downgrade et annulation immédiate. Les scénarios doivent préciser les impacts sur la facturation et la date de renouvellement. Livrable attendu Une suite de scénarios BDD décrivant précisément les règles financières métier.

Contexte Un moteur de règles permet aux administrateurs de configurer dynamiquement des conditions déclenchant des actions automatiques. Le Problème Le comportement attendu selon différentes configurations n’est pas formalisé. Contraintes Créer des scénarios couvrant règle active, règle désactivée et conflit entre deux règles. Les scénarios doivent décrire les effets observables côté utilisateur final. Livrable attendu Une suite de scénarios BDD décrivant clairement le fonctionnement dynamique du moteur de règles.

Contexte Une plateforme applique des règles de tarification dynamiques selon profil client, période et promotions cumulables ou exclusives. Le Problème La logique métier est complexe et non formalisée en BDD. Contraintes Créer des scénarios couvrant : client standard sans promotion, client premium avec remise cumulée, promotions exclusives et conflit de règles. Les scénarios doivent exprimer clairement les règles métier sans détailler l’implémentation. Livrable attendu Une suite de scénarios Given When Then décrivant précisément les décisions tarifaires attendues.

Contexte Un système gère des rôles hiérarchiques avec délégation temporaire de permissions. Le Problème Les règles d’héritage et de délégation ne sont pas décrites formellement. Contraintes Créer des scénarios couvrant héritage automatique, délégation temporaire active et expiration de délégation. Les scénarios doivent rester orientés métier et comportement observable. Livrable attendu Un ensemble structuré de scénarios BDD décrivant précisément la logique d’autorisation.

Contexte Un processus de validation interne comprend plusieurs étapes conditionnelles selon le montant et le département concerné. Le Problème Les conditions dynamiques ne sont pas formalisées. Contraintes Créer des scénarios couvrant validation simple, validation nécessitant deux approbations et rejet à une étape intermédiaire. Les scénarios doivent préciser les conditions déclenchant chaque étape. Livrable attendu Une suite complète de scénarios BDD décrivant fidèlement le workflow métier.