Discussion :

[vinou33]

Bonjour,

Je suis un peu perdu suite à la lecture d'un livre sur JUnit.
Quelqu'un pourrait, s'il vous plaît, m'expliquer la partie
Test behavior vs implementation?

Je vous remercie d'avance pour la prise en considération de cette requête.

Cordialement,

Vinz

[Pill_S]

Hors contexte c'est un peu difficile de savoir vraiment de quoi tu parles Mais quand on parle de test et de behavior dans la même phrase, ça me fait penser au concept de BDD -> Behavior Driven Development, c'est à dire, une manière d'écrire des tests qui, contrairement aux tests unitaires classiques, ne teste pas les détails d'implémentation d'une partie de code bien isolée, mais plutôt le comportement d'un ensemble d'interactions en utilisant un langage quasiment naturel. En cela, le BDD est une forme de test d'intégration et non plus un test unitaire. Plus d'infos avec les frameworks Cucumber (https://cucumber.io), JBehave (https://jbehave.org) ou encore JGiven (http://jgiven.org) qui sont des "extensions" à JUnit.

C'est pas facile à expliquer, mais le concept central du BDD est que tu écris des scénarios en langage quasiment naturel (ça pourrait même être le business analyst qui les écrit, même si en pratique c'est une utopie), et avec quelques glues techniques, tu fais en sorte de mapper l'expression de ces scénarios vers le code correspondants:

Un scénario pourrait s'écrire comme ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
# Scénario "le total est calculé correctement"
En tant qu'utilisateur
Lorsque je créé une nouvelle facture destinée au client Toto
Et que j'ajoute un élément coutant 30€ à la facture
Alors le total de la facture est de 30€
Et la balance du client Toto devient -30€

... le parser du framework (combiné à du code customisé - aka la fameuse "glue" technique) va analyser la structure de l'ensemble et initialiser une nouvelle facture, l'attribuer à Toto, ajouter un élément à cette facture, puis finalement vérifier que le total vaut 30€ et que la balance du client Toto est de -30€.

Je schématise et prend quelques raccourcis, mais l'idée est là.

Il va de soit que l'on n'utilise plus de mocks dans le cadre de ce genre de tests (tests d'intégration).

[vinou33]

En tout premier lieu, je te remercie pour ta réponse. Néanmoins, mon petit cerveau n'a pas tout compris. En fait, je parle de ce que l'on trouve aussi sur des blogs:
https://teamgaslight.com/blog/testin...implementation
Désolé, je suis un gros naze en anglais. Par contre, BDD est une autre version de TDD ?

Je remercie d'avance pour les réponses.

Cordialement,

Vinz

[Pill_S]

En fait, je parle de ce que l'on trouve aussi sur des blogs:
https://teamgaslight.com/blog/testin...implementation

Alors ça semble être ça en effet ^^ les frameworks que j'ai cité sont des moyens techniques de mettre en place des tests de comportement.

Par contre, BDD est une autre version de TDD ?

Nope, BDD est un sous-type du TDD. TDD veut dire qu'on utilisera des tests pour toutes les parties du développement. BDD veut dire qu'on aura une partie des tests dédiés à la vérification du comportement global, sans s'intéresser aux détails (en opposition aux tests unitaires qui ne s'intéressent qu'au fonctionnement d'une toute petite partie du code). BDD + Test unitaires + tests d'intégration = TDD (en simplifié).

[vinou33]

Merci encore une fois. Et dernière question : qu'est ce qui est le mieux donc ?

[Pill_S]

dernière question : qu'est ce qui est le mieux donc ?

Les deux mon capitaine

Ils sont complémentaires, et ne couvrent pas les mêmes objectifs. Selon la doctrine TDD, on doit commencer par les tests unitaires et avoir une grand couverture, puis ensuite investir dans les tests d'intégration (avec du BDD ou pas, c'est à choix). Mais le socle des tests, c'est les tests unitaires.

[Pill_S]

* même si personnellement, je trouve que le retour sur investissement est meilleur avec les tests d'intégration et le bdd - mais ça c'est un avis personnel subjectif

[vinou33]

OK. Merci pour les retours et bonne journée.