Quelles sont les différences entre les frameworks BDD pour Java?
Quels sont les avantages et les inconvénients de chaque Behavior Driven Development (BDD) framework pour Java?
J'en ai trouvé certains ici , par exemple.
Est-il judicieux d'utiliser un framework BDD si j'utilise déjà une bibliothèque de simulation (par exemple Mockito )?
Je viens de terminer la comparaison de trois frameworks BDD pour Java. Évidemment, mes résultats ont une date limite de consommation assez courte.
- Très souple
- Très jolie sortie de rapport
- Beau cadre de plugin
- Mal documenté. J'ai dû lire la source pour le comprendre (heureusement sa très bonne qualité).
- Les appareils semblaient susceptibles de se retrouver étroitement couplés au HTML.
- Courbe d'apprentissage très peu profonde (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 (edit: en fait, il y en a mais la documentation était très bien cachée).
- L'histoire et le code sont très étroitement couplés (même fichier)
- Sortie de rapport très basique
- Impossible de faire fonctionner le plugin IntelliJ
- Communauté inactive (le plugin Maven semble avoir été cassé pendant trois mois - pas beaucoup d'exemples de code sur lesquels s'appuyer)
- Extrêmement puissant et flexible (par exemple, réduction de la plaque de la chaudière grâce à la composition d'histoires comme conditions préalables)
- Documentation et exemples détaillés (s'ils sont fragmentés)
- Prise en charge étendue (si é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 sur le web.
- Une courbe d'apprentissage assez abrupte (il m'a fallu 3-4 fois plus de temps pour 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 pour le moment.
"avantages et inconvénients" peuvent être des choses différentes pour différentes personnes. Je regarde habituellement
- activité de développement , par ex. sont des nouvelles versions probables ou est la dernière version datant de 2 ans.
- maturité , par ex. depuis combien de temps il existe, existe-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.)
- prise en charge des outils , par ex. existe-t-il un plugin Eclipse, un 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 choisir moi-même mon cadre moqueur.
- type de licence , ceci est important pour moi en raison des conditions légales de l'entreprise pour laquelle je travaille.
- compatibilité avec les outils associés , par ex. utilise-t-il ou non le langage Gherkin?.
Et à partir de certains cadres, j'ai regardé
- Instinct mauvais : dernière activité mars 2010 , bon : licence ASF
- JDave mauvais : livré avec des égaliseurs et moqueurs, 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 ce serait 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 : il semble aller dans l'autre sens, en créant un rapport à partir du code.
- spock mauvais : peut-être un peu extrême , c'est un framework de test complet, pas seulement BDD, bon : très actif, très cool.
- jbehave, la "mère" de tous les BDD en Java, mauvaise : très puissant = licence complexe et incompatible (pour moi), livré avec presque toutes les bibliothèques de test et bien plus, 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 Ruby RSpec mais utilisant Java lambda (au lieu d'annotations) pour vous permettre de créer des tests hautement contextuels et très lisibles. Simple. 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 à rédiger les spécifications, mais certains tests nécessiteront des simulations ou des talons, en particulier. lorsque vous concevez de haut en bas (de l'aperçu au détail).
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 Java Based Acceptance Testing
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 de simulation (par exemple Mockito)?
Réponse courte: oui, certainement. En fait, les tests d'acceptation utilisant un framework BDD et les tests unitaires isolés avec des objets fictifs sont si différents que je ne comprends pas vraiment la question. Les tests d'acceptation sont des tests de 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 à l'aide de simulateurs 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 cadre BDD et l'inverse est également vrai.
À l'origine, j'ai fait mon BDD avec jUnit ordinaire, mais j'ai regardé JDave récemment parce que c'est presque 1: 1 par rapport à 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 d'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 simulacres! Ils ne sont pas spécifiquement liés au TDD/BDD, leur objectif est d'alléger le fardeau des tests en général.
Wow, je vois que le sujet est chaud, beaucoup de bonnes réponses ...
Ironie du sort, j'ai récemment découvert BDD et 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 également faire défaut dans certains projets ... Ou tout simplement manquer de précision que BDD oblige à introduire.
L'article Behaviour Driven Development résume le concept et propose 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 cadre 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 rapides/tutoriel et de voir lequel semble le plus adapté à votre style. D'autres critères pourraient être le fait qu'un framework exploite des outils que vous connaissez (test unitaire, simulation), une utilisation avec l'IDE, 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é en texte brut.
Il peut être exécuté comme test JUnit. Donc, le seul problème pour commencer à utiliser est de faire en sorte que les gens d'affaires ou le chef de produit lisent/écrivent des fonctionnalités dans les sources.
Résultats
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.
Mon équipe utilise JBehave depuis un certain temps. Il utilise des fichiers en texte brut pour stocker les spécifications. Chaque étape (Given, When, Then) est ensuite exécutée par une certaine méthode qui peut extraire des paramètres de l'étape. Les scénarios peuvent être en retrait 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 pendant l'exécution. Cela peut causer beaucoup de problèmes pour déterminer où est le bogue.