A quel niveau se place le BDD
Rémy Sanlaville
Depuis un moment je me pose la question de savoir à quel niveau se place le BDD ou non.
Prenons par exemple le cas d'un logiciel qui est découpé en plusieurs modules.
Certains modules sont gérés par des équipes différentes.
|-------------------- Logiciel -------------------------
| ---------------- ---------------- |
User --- | | module 1 | --- | module 2 | --- ... |
| ---------------- ---------------- |
|-------------------- Logiciel -------------------------
Est-ce que le BDD ne s'applique qu'au niveau du logiciel ou aussi aux modules ?
Est-ce que le niveau module n'est pas déjà une solution et n'est pas trop technique/générique ?
Qu'en pensez-vous ?
Rémy
Luc Jeanniard
C'est un bon sujet de réflexion en effet. Je pense que le Behavior Driven Development doit être accessible à nos utilisateurs embarqués et ProductOwners. Le BDD est un outil qui peut être utilisé à tous les niveaux - comme XUnit d'ailleurs - donc c'est vraiment au niveau des pratiques qu'il faut être vigilant.
Mon expérience sur des gros projets (plusieurs équipes, plusieurs années) est qu'il est assez facile d'obtenir une grosse pagaille dans les tests BDD. En effet, plus le projet avance, plus le nombre de steps est grand et le risque de duplication, code complexe augmente fortement; la maintenance peut alors devenir très coûteuse. Il devient même difficile de trouver les steps déjà écris. Donc il me semble que rester à un niveau utilisateur permet de mieux maîtriser la suite de spécifications exécutables car le nombre d'actions utilisateurs augmente beaucoup moins vite que le nombre de services rendus par les modules qui composent l'application. D'autres types de tests doivent par ailleurs couvrir le comportement des classes et modules - cf pyramide de tests.
Luc
Rémy Sanlaville
C'est un bon sujet de réflexion en effet. Je pense que le Behavior Driven Development doit être accessible à nos utilisateurs embarqués et ProductOwners. Le BDD est un outil qui peut être utilisé à tous les niveaux - comme XUnit d'ailleurs - donc c'est vraiment au niveau des pratiques qu'il faut être vigilant.
Mon expérience sur des gros projets (plusieurs équipes, plusieurs années) est qu'il est assez facile d'obtenir une grosse pagaille dans les tests BDD. En effet, plus le projet avance, plus le nombre de steps est grand et le risque de duplication, code complexe augmente fortement; la maintenance peut alors devenir très coûteuse. Il devient même difficile de trouver les steps déjà écris. Donc il me semble que rester à un niveau utilisateur permet de mieux maîtriser la suite de spécifications exécutables car le nombre d'actions utilisateurs augmente beaucoup moins vite que le nombre de services rendus par les modules qui composent l'application. D'autres types de tests doivent par ailleurs couvrir le comportement des classes et modules - cf pyramide de tests.
Si j'ai bien compris, ton avis est plutôt d'utiliser le BDD au niveau utilisateur (et donc logiciel dans mon schéma) et ne pas l'utiliser pour les modules internes.
Est-ce bien cela ?
Rémy
Luc Jeanniard
Oui, pour moi le bdd c'est au niveau logiciel et pas au niveau module. La
technicité des tests est quand même fonction du type de logiciel developpé;
je veux dire par là que si ton client demande qq de très technique, les
tests serons techniques mais à son niveau.
Envoyé de mon iPhone
Rémy Sanlaville
Merci pour la confirmation.
Du coup j'en profite pour creuser un peu plus le sujet.
Imaginons qu'un des modules est utilisé par plusieurs applicatifs et qu'il est géré comme un projet avec son propre budget et sa propre une équipe... Est-ce qu'il pourrait être géré en BDD ou non ?
Rémy
Luc Jeanniard
Sinon, des tests unitaires sont probablement plus adaptés.
Luc
Laurent Bristiel
Chez nous, on a le cas d'un module technique dont plusieurs
applicatifs sont utilisateurs.
On pourrait très bien tester ce module en BDD.
En l'occurence on fait du test after mais les tests sont fonctionnels
et de type "As a user..."
Laurent
On Mar 7, 3:55 am, Luc Jeanniard <luc.jeanni...@gmail.com> wrote:
> Je dirais que si il y a des user stories, c'est possible ... Mais des vrais
> user stories : As a <user> I want ... So that ...
>
> Sinon, des tests unitaires sont probablement plus adaptés.
>
> Luc
>
MILLET LUC
De ce que j'en ai compris, le BDD est indépendant du découpage par projet.
Dans les projets que j'ai géré, le découpage par composants sert à limiter la complexité à gérer : par exemple, limiter les effets de bords entre parties lors des changements d'un composant, ou détection d'un effet de bord lors si impact sur les interfaces d'échanges.
Chaque composant a ses propres tests pour le valider (donc tous les niveaux de tests), et devient un entrant pour le(s) composant(s) qui l'utilise(nt).
Le BDD est plus lié à la complexité du point à tester, et c'est une étape supplémentaire pour se rapprocher de la formulation du demandeur en partant de la technique.
De ce que je vois, dans la logique des xDD, on a donc :
TDD : test d'état
BDD : test de comportement
prochaine étape prévisible => GDD : test de but
Pour en revenir à la formulation du besoin :
Dans les approches plus classiques, on part du besoin pour aller vers la solution.
Avantage : plus simple pour définir le besoin (souvent, le définisseur du besoin n'est pas technique), et réponse pas limitée à une approche particulière.
Inconvénient : souvent plus complexe pour traduire en technique et/ou plus lourd, surtout quand le lien entre besoin et solution est direct.
Or les avancées actuelles dans les approches agiles partent de la solution (moyens techniques) pour remonter vers le besoin, avec à chaque étape la volonté de pouvoir automatiser la vérification de la traduction du besoin en solution.
Avantage : si besoin directement traductible techniquement, plus rapide à implémenter, cycles plus courts.
Inconvénient : souvent, le besoin est exprimé en solution technique... Et risque que la technique réduise la réponse au besoin à ses propres limites... ("pour qui possède un marteau, tout problème ressemble à un clou" P. Watzlawick => mais quand le problème est un clou, pas de temps perdu à chercher l'outil adapté...)
Sauf dans des cas très simples, une approche mixte permet de converger plus rapidement.
Luc
________________________________________
De : cara-ase...@googlegroups.com [cara-ase...@googlegroups.com] de la part de Laurent Bristiel [laurent....@gmail.com]
Date d'envoi : mercredi 7 mars 2012 21:29
À : CARA ASEGrenoble
Objet : Re: A quel niveau se place le BDD