miércoles
oct142009
Herramientas ACT para Java: Concordion y Cucumber
miércoles, octubre 14, 2009 at 12:59AM
Para los que nunca han oído hablar de Automated Acceptance Test (Pruebas de aceptación automatizadas), éstas son "pruebas que se ejecutan al inicio de cada iteración y son una forma ejecutable de los requisitos" (Amr Elssamadisy). Lo ideal es que se construyan en una herramienta que permita usar lenguaje del negocio y que dicha herramienta se encargue de traducir a pruebas unitarias capaces de ejecutarse sobre el código fuente. Obviamente, se llaman de aceptación porque si el producto resultante de la iteración pasa todas las pruebas, esto quiere decir que se cumplieron con los requisitos establecidos.
Oliver Wehrens en su blog MaxHeapSize ha hecho una comparación de dos herramientas de ACT que pueden usarse en Java: Concordion y Cucumber. La primera 100% java y la segunda Ruby, que gracias a JRuby podemos usar en nuestra JVM sin problemas. A estas dos, yo agregaría easyb que usa un DSL groovy para escribir las pruebas aunque al usar un Groovy, normalmente no las escribiría el usuario de negocio, como sí sucede en una herramienta ACT.
En el blog de Oliver, puedes ver la comparativa. Aquí sólo me haré eco de sus conclusiones:
Concordion:
Pros:
Contras:
Cucumber
Pros:
Contras:
Un esfuerzo como el de ACT va englobado dentro de Behaviour Driven Development (BDD), un enfoque que busca involucrar desde un inicio a los usuarios de negocio (stakeholders, analistas de negocio, etc) junto con los programadores y el personal de QA con el fin de mejorar el resultado del producto de cada iteración. La idea es que desde un principio se tengan las especificaciones del producto en una forma que puedan ejecutarse sobre dicho producto para verificar si las cumplen o no. ¿Qué te parece esta técnica, acostumbras usarla, qué herramientas usas para ello?
Oliver Wehrens en su blog MaxHeapSize ha hecho una comparación de dos herramientas de ACT que pueden usarse en Java: Concordion y Cucumber. La primera 100% java y la segunda Ruby, que gracias a JRuby podemos usar en nuestra JVM sin problemas. A estas dos, yo agregaría easyb que usa un DSL groovy para escribir las pruebas aunque al usar un Groovy, normalmente no las escribiría el usuario de negocio, como sí sucede en una herramienta ACT.
En el blog de Oliver, puedes ver la comparativa. Aquí sólo me haré eco de sus conclusiones:
Concordion:
Pros:
- Puede procesar texto libre para ejecutar las pruebas
- El informe final es vistoso
- Soporte JUnit
- Fácil de instalar
- 100% Java
Contras:
- Quien escriba los Features debe saber algo de HTML.
- Normalmente, el programador tendrá que modificar el HTML para poder ejecutar las pruebas.
- Parte de tu aplicación estará en HTML.
- Sin soporte para TestNG
Cucumber
Pros:
- Las Features se pueden escribir en texto plano y en 36 lenguajes humanos (incluyendo el castellano)
- Normalmente, no se tendrán que modificar las Features.
- La instrumentación de las pruebas se escriben directamente en tu código java mediante anotaciones
Contras:
- Más complejo por el hecho de tener que usar Ruby/JRuby/Java. (Oliver no da más detalles sobre este punto)
- Quien escriba las pruebas, se debe atener a un formato predefinido.
- Oliver no encontró una forma de ejecutar un runner automático para las pruebas, esto se tendrá que hacer mediante Ant o Maven.
- Sin soporte para JUnit o TestNG.
Un esfuerzo como el de ACT va englobado dentro de Behaviour Driven Development (BDD), un enfoque que busca involucrar desde un inicio a los usuarios de negocio (stakeholders, analistas de negocio, etc) junto con los programadores y el personal de QA con el fin de mejorar el resultado del producto de cada iteración. La idea es que desde un principio se tengan las especificaciones del producto en una forma que puedan ejecutarse sobre dicho producto para verificar si las cumplen o no. ¿Qué te parece esta técnica, acostumbras usarla, qué herramientas usas para ello?
in
j2se
j2se 
Reader Comments