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)
+1: con mucho, la mejor respuesta aquí. Añadiendo enlaces.
haylem
35
"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).
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.
Lo que dijo no está mal, pero eso no significa que no pueda escribir sus pruebas unitarias en un estilo más amigable con BDD. No es una especificación por ejemplo, pero tampoco es una característica inútil. docs.mockito.googlecode.com/hg/org/mockito/BDDMockito.html
cwash
7
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.
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.
@Boris ¿Podría ser su problema que los pasos PENDIENTES cuenten como aprobados (el comportamiento predeterminado) en lugar de fallar? Si ese es su problema, puede configurar la estrategia PendingErrorStrategy: jarvana.com/jarvana/view/org/jbehave/jbehave-core/2.2.1/…
JeffH
3
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.
Respuestas:
Acabo de terminar de comparar tres marcos BDD para Java. Obviamente, mis hallazgos tienen una fecha de caducidad bastante corta.
Concordia
EasyB
JBehave
No tuve la oportunidad de probar Cuke4Duke de JDave como me hubiera gustado, pero probablemente presionaré por JBehave en este momento.
fuente
"pros y contras" pueden ser cosas diferentes para diferentes personas. Yo suelo echar un vistazo a
Y desde algunos marcos eché un vistazo a
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).
fuente
Aquí hay un enlace interesante sobre Concordion vs. Cucumber y Pruebas de aceptación basadas en Java
Realmente, mira el mencionado anteriormente.
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.
fuente
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.
fuente
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.
fuente
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
fuente
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.
fuente
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.
fuente