Quelles sont les différences entre les frameworks BDD pour Java? [fermé]

Quels sont les avantages et les inconvénients de chaque framework BDD ( Behavior Driven Development ) pour Java?

J'en ai trouvé quelques-uns ici , par exemple.

Est-il judicieux d'utiliser un framework BDD si j'utilise déjà une bibliothèque moqueuse (par exemple Mockito )?

Je viens de terminer la comparaison de trois frameworks BDD pour Java. De toute évidence, mes résultats ont une date limite d'utilisation assez courte.

Concordion

• Très souple
• Très jolie sortie de rapport
• Cadre de plugin sympa
• Mal documenté. J'ai dû lire la source pour le comprendre (heureusement, sa qualité est extrêmement bonne).
• Les luminaires semblaient susceptibles de finir étroitement liés au html.

EasyB

• Courbe d'apprentissage très superficielle (même pour les développeurs non Groovy)
• Intégration DBUnit extrêmement puissante
• Apparemment, aucun support pour les paramètres (conduit à des histoires très vagues ou à une duplication entre le texte et le code (modifier: en fait, il y en a mais la documentation était très bien cachée.)
• L'histoire et le code sont très étroitement liés (même fichier)
• Sortie de rapport très basique
• Impossible de faire fonctionner le plugin IntelliJ
• Communauté inactive (le plugin Maven semble être cassé depuis trois mois - peu d'exemples de code sur lesquels s'appuyer)

JBehave

• Extrêmement puissant et flexible (par exemple réduction de la plaque chauffante grâce à la composition des étages comme pré-requis)
• Documentation et exemples détaillés (si fragmentés)
• Prise en charge étendue (voire écrasante) de différents cadres et environnements
• Excellente séparation des fichiers d'histoire du code
• Semble avoir une communauté assez active et beaucoup plus d'exemples et de discussions à ce sujet sur le Web.
• Une courbe d'apprentissage assez raide (m'a pris 3 à 4 fois plus de temps à comprendre que Concordion / EasyB)

Je n'ai pas eu la chance d'essayer Cuke4Duke de JDave comme je l'aurais souhaité, mais je vais probablement pousser pour JBehave à ce moment.

Les «avantages et inconvénients» peuvent être des choses différentes pour différentes personnes. Je regarde habituellement

• activité de développement , par exemple de nouvelles versions sont-elles probables ou la dernière version date-t-elle de 2 ans.
• maturité , par exemple depuis combien de temps existe-t-il, y a-t-il des tutoriels et peut-être même des livres disponibles. (Je ne lis pas ces livres, c'est juste un signe d'adoption.)
• support des outils , par exemple existe-t-il un plugin Eclipse, support Ant, etc.
• taille des dépendances , je n'aime pas les frameworks qui viennent avec tout ce qui leur est propre. Par exemple, je veux moi-même choisir mon cadre moqueur.
• type de licence , c'est important pour moi en raison des conditions légales de l'entreprise pour laquelle je travaille.
• compatibilité avec les outils associés , par exemple utilise-t-il le langage Gherkin ou non.

Et à partir de certains cadres, j'ai jeté un coup d'œil à

• Instinct mauvais : dernière activité mars 2010, bon : licence ASF
• JDave mauvais : livré avec des matchers et des mocks, bon : dernière activité janvier 2011, licence ASF
• easyb mauvais : dernière activité oct 2010, pas sûr : il utilise Groovy. Cela pourrait être correct, mais cela poserait un problème d'adoption dans mon cas.
• beanspec mauvais : une seule version en 2007, c'est mort
• bdoc mauvais : dernière activité en janvier 2010, pas sûr : on dirait aller dans l'autre sens, créer un rapport à partir du code.
• spock mauvais : peut-être un peu extrême, c'est un cadre de test complet, pas seulement BDD, bon : très actif, très cool.
• jbehave , la "mère" de tous les BDD en Java, mauvais : très puissant = licence complexe et incompatible (pour moi), est livré avec presque toutes les bibliothèques de test et bien plus encore, bon : basé sur RSpec et donc compatible, plugins eclipse, intégration maven , communauté très active
• ginkgo4j , un framework BDD pour Java également basé sur le RSpec de Ruby mais utilisant des lambda de Java (au lieu d'annotations) pour vous permettre de créer des tests hautement contextuels et hautement lisibles. Facile. Très puissant. Licence Open source Apache 2.

Concernant les simulacres: Vous avez certainement besoin d'un cadre moqueur également. Les frameworks BDD vous aident simplement à écrire les spécifications, mais certains tests nécessiteront des simulations ou des stubs, en particulier. lorsque vous concevez de haut en bas (de la vue d'ensemble aux détails).

Quel est le meilleur framework BDD à utiliser avec Java? Pourquoi? Quels sont les avantages et les inconvénients de chaque cadre?

Voici un lien intéressant sur Concordion vs Cucumber et les tests d'acceptation basés sur Java

J'en ai trouvé quelques-uns ici, mais je ne sais pas lequel choisir.

Vraiment, regardez celui mentionné ci-dessus.

Est-il judicieux d'utiliser un framework BDD si j'utilise déjà une bibliothèque moqueuse (par exemple Mockito)?

Réponse courte: oui, certainement. En fait, les tests d'acceptation utilisant un framework BDD et les tests unitaires isolés utilisant des objets factices sont si différents que je ne comprends pas vraiment la question. Les tests d'acceptation sont des tests boîte noire, les tests sont utilisés pour vérifier qu'une fonctionnalité métier fonctionne et sont idéalement écrits par un analyste métier. Les tests unitaires isolés utilisant des simulations sont des tests en boîte blanche, les tests sont utilisés pour vérifier qu'une unité fonctionne et sont écrits par les développeurs. Les deux sont utiles mais ils ont des objectifs totalement différents. En d'autres termes, l'utilisation de Mockito ne remplace pas du tout un framework BDD et l'inverse est également vrai.

J'ai initialement fait mon BDD avec jUnit ordinaire, mais j'ai regardé JDave ces derniers temps parce que c'est presque 1: 1 à ce que je faisais avec jUnit. Il fonctionne également sur jUnit, il fonctionne donc déjà sur Eclipse et est également facile à configurer pour fonctionner sur des systèmes d'intégration continue tels que Hudson. Je ne peux pas vraiment le comparer avec les autres, mais mes expériences avec JDave ont été bonnes jusqu'à présent.

Oh et ce n'est jamais une idée stupide d'utiliser des simulations! Ils ne sont pas liés spécifiquement au TDD / BDD, leur but est d'alléger le fardeau des tests en général.

Wow, je vois que le sujet est brûlant, plein de bonnes réponses ...

Ironie mise à part, j'ai récemment découvert BDD et j'ai trouvé le concept intéressant. Hé, ça oblige à écrire à la fois des tests ... et des spécifications! Aussi surprenant que cela puisse paraître, ce dernier peut aussi manquer dans certains projets ... Ou tout simplement manquer de la précision que BDD oblige à introduire.

L' article sur le développement axé sur le comportement résume le concept et des liens vers de bons articles (comme celui écrit par Andrew Glover). De plus, au sujet de ce fil, il donne une liste assez complète (je suppose) des frameworks BDD, un bon nombre d'entre eux étant pour Java.
Cela ne résout pas le problème du choix du framework mais au moins cela facilitera la recherche ...

Étant donné que BDD s'appuie fortement sur la lisibilité du code de test, je suppose qu'un bon critère de choix est de regarder les visites / tutoriels rapides et de voir lequel semble le plus adapté à votre style. D'autres critères pourraient être le fait qu'un framework tire parti des outils avec lesquels vous êtes familier (test unitaire, moquage), l'utilisation avec l'EDI, etc.

J'ai essayé Cucumber-JVM (précédemment développé sous le nom de Cuke4Duke). Il utilise Gherkin DSL pour la spécification, stocké sous forme de texte brut.

Il peut être exécuté comme un test JUnit. Donc, le seul problème pour commencer à l'utiliser est de faire en sorte que les gens d'affaires ou le chef de produit lisent / écrivent des .features dans les sources.

Résultats

Mon équipe utilise JBehave depuis un certain temps. Il utilise des fichiers texte brut pour stocker les spécifications. Chaque étape (Donné, Quand, Alors) est ensuite exécutée par une certaine méthode qui peut extraire les paramètres de l'étape. Les scénarios peuvent être indentés et bien formatés, ce qui aide beaucoup si les clients veulent les vérifier.

Il y a aussi des problèmes. Nous sommes passés à Java 6. Parfois, certaines étapes du scénario sont ignorées lors de l'exécution. Cela peut causer beaucoup de problèmes pour déterminer où se trouve le bogue.

Mon équipe a utilisé JBehave avec succès - nous y sommes passés après avoir utilisé EasyB et avons trouvé les fichiers de scénario en texte brut plus faciles à gérer.