¿Cuáles son las diferencias entre los marcos BDD para Java? [cerrado]

¿Cuáles son los pros y los contras de cada marco de desarrollo basado en el comportamiento (BDD) para Java?

He encontrado algunos de ellos aquí , por ejemplo.

¿Tiene sentido usar un marco BDD si ya uso una biblioteca simulada (por ejemplo, Mockito )?

Acabo de terminar de comparar tres marcos BDD para Java. Obviamente, mis hallazgos tienen una fecha de caducidad bastante corta.

Concordia

• Muy flexible
• Muy bonito informe de salida
• Bonito marco de plugins
• Mal documentado Tuve que leer la fuente para descubrirlo (afortunadamente es de muy buena calidad).
• Los accesorios parecían estar muy unidos al html.

EasyB

• Curva de aprendizaje muy superficial (incluso para desarrolladores que no son Groovy)
• Integración DBUnit extremadamente poderosa
• Aparentemente no hay soporte para parámetros (conduce a historias muy vagas o duplicación entre texto y código (editar: en realidad existe, pero la documentación estaba muy bien oculta).
• La historia y el código están muy unidos (mismo archivo)
• Salida de informe muy básica.
• No se pudo hacer funcionar el complemento IntelliJ
• Comunidad inactiva (el complemento de Maven parece haber estado roto durante tres meses; no hay muchos ejemplos de código para aprovechar)

JBehave

• Extremadamente potente y flexible (por ejemplo, reducción de la placa de la caldera mediante la composición de historias como requisitos previos)
• Amplia documentación (si está fragmentada) y ejemplos
• Amplio (aunque abrumador) soporte para diferentes marcos y entornos.
• Excelente separación de archivos de historia del código
• Parece tener una comunidad bastante activa y muchos más ejemplos y debates en la web.
• Una curva de aprendizaje bastante pronunciada (tardé 3-4 veces más en descubrir que Concordion / EasyB)

No tuve la oportunidad de probar Cuke4Duke de JDave como me hubiera gustado, pero probablemente presionaré por JBehave en este momento.

"pros y contras" pueden ser cosas diferentes para diferentes personas. Yo suelo echar un vistazo a

• actividad de desarrollo , por ejemplo, ¿son probables nuevas versiones o es la última versión que tiene 2 años?
• madurez , por ejemplo, cuánto tiempo ha estado disponible, ¿hay tutoriales y tal vez incluso libros disponibles? (No leo estos libros, es solo una señal de adopción).
• soporte de herramientas , por ejemplo, ¿hay un complemento Eclipse, soporte Ant, etc.
• tamaño de las dependencias , no me gustan los marcos que vienen con todo lo suyo. Por ejemplo, quiero elegir mi marco burlón yo mismo.
• tipo de licencia , esto es importante para mí debido a los términos legales en la empresa para la que trabajo.
• compatibilidad con herramientas relacionadas , por ejemplo, usa el lenguaje Gherkin o no.

Y desde algunos marcos eché un vistazo a

• Instinto malo : última actividad marzo de 2010, bueno : licencia ASF
• JDave malo : viene con imitadores y simulacros, bueno : última actividad enero de 2011, licencia ASF
• easyb malo : última actividad octubre de 2010, no estoy seguro : utiliza Groovy. Esto podría estar bien, pero sería un problema para la adopción en mi caso.
• beanspec malo : solo una versión en 2007, esto está muerto
• bdoc incorrecto : última actividad en enero de 2010, no estoy seguro : parece que va a la inversa, creando un informe a partir del código.
• Spock mal : tal vez un poco extremo, este es un marco de prueba completo, no solo BDD, bueno : muy activo, muy genial.
• jbehave , la "madre" de todos los BDD en Java, mala : muy poderosa = licencia compleja e incompatible (para mí), viene con casi todas las bibliotecas de prueba y mucho más, buena : basada en RSpec y por lo tanto compatible, complementos de eclipse, integración maven comunidad muy activa
• ginkgo4j , un marco BDD para Java también basado en RSpec de Ruby, pero que usa lambda de Java (en lugar de anotaciones) para permitirle crear pruebas altamente contextuales y legibles. Sencillo. Muy poderoso. Licencia de código abierto Apache 2.

Con respecto a los simulacros: definitivamente también necesita un marco de imitación. Los marcos BDD simplemente lo ayudan a escribir las especificaciones, pero algunas pruebas necesitarán simulacros o trozos, especialmente. cuando diseñas de arriba hacia abajo (desde la descripción general hasta los detalles).

¿Cuál es el mejor marco BDD para usar con Java? ¿Por qué? ¿Cuáles son los pros y los contras de cada marco?

Aquí hay un enlace interesante sobre Concordion vs. Cucumber y Pruebas de aceptación basadas en Java

He encontrado un par de ellos aquí, pero no estoy seguro de cuál elegir.

Realmente, mira el mencionado anteriormente.

¿Tiene sentido usar un marco BDD si ya uso una biblioteca simulada (por ejemplo, Mockito)?

Respuesta corta: sí, definitivamente. En realidad, las pruebas de aceptación usando un marco BDD y las pruebas unitarias aisladas usando objetos simulados son tan diferentes que realmente no entiendo la pregunta. La prueba de aceptación es una prueba de recuadro negro, las pruebas se utilizan para verificar que una característica comercial está funcionando y están idealmente escritas por analistas comerciales. Las pruebas unitarias aisladas utilizando simulacros son pruebas de caja blanca, las pruebas se utilizan para verificar que una unidad funciona y están escritas por desarrolladores. Ambos son útiles, pero tienen propósitos totalmente diferentes. En otras palabras, el uso de Mockito no reemplaza un marco BDD en absoluto y lo inverso también es cierto.

Originalmente hice mi BDD con jUnit simple, pero últimamente he estado mirando JDave porque es casi 1: 1 a lo que estaba haciendo con jUnit. También se ejecuta sobre jUnit, por lo que ya funciona en Eclipse y también es fácil de configurar para trabajar en sistemas de integración continua como Hudson. Realmente no puedo compararlo con otros, pero mis experiencias con JDave han sido buenas hasta ahora.

¡Ah, y nunca es una estúpida idea usar simulacros! No están vinculados específicamente con TDD / BDD, su propósito es aliviar la carga de las pruebas en general.

Wow, veo que el tema es candente, muchas buenas respuestas ...

Dejando de lado la ironía, recientemente descubrí BDD y encontré el concepto interesante. ¡Oye, obliga a escribir ambas pruebas ... y especificaciones! Por sorprendente que parezca, este último también puede faltar en algunos proyectos ... O simplemente falta la precisión que BDD obliga a introducir.

El artículo sobre Desarrollo impulsado por el comportamiento resume el concepto y los enlaces a algunos buenos artículos (como el escrito por Andrew Glover). Además, con el tema de este hilo, ofrece una lista bastante completa (supongo) de los marcos de BDD, un buen número de ellos para Java.
No resuelve el problema de elegir el marco, pero al menos facilitará la búsqueda ...

Dado que BDD se basa en gran medida en la legibilidad del código de prueba, supongo que un buen criterio de elección es mirar los recorridos rápidos / tutoriales y ver cuál parece más adecuado para su estilo. Otro criterio podría ser el hecho de que un marco aprovecha las herramientas con las que está familiarizado (prueba unitaria, simulación), uso con IDE, etc.

Probé Pepino-JVM (previamente desarrollado como Cuke4Duke). Utiliza Gherkin DSL para la especificación, almacenado como texto sin formato.

Se puede ejecutar como una prueba JUnit. Entonces, el único problema para comenzar a usarlo es hacer que las personas de negocios o el Gerente de Producto lean / escriban características.

Resultados

Mi equipo ha estado usando JBehave por algún tiempo. Utiliza archivos de texto sin formato para almacenar especificaciones. Cada paso (Dado, Cuándo, Entonces) se ejecuta mediante un determinado método que puede extraer parámetros del paso. Los escenarios pueden ser sangrados y bien formateados, lo que ayuda mucho si los clientes desean verificarlos.

También hay algunos problemas. Hemos cambiado a Java 6. A veces, algunos pasos del escenario se ignoran durante la ejecución. Puede causar muchos problemas para descubrir dónde está el error.

Mi equipo ha utilizado JBehave con éxito: nos mudamos a él después de usar EasyB y encontramos que los archivos de escenarios de texto sin formato son más fáciles de manejar.