Etiquetas: j2se, cucumber, easyb, concordion, jruby, act, bdd
En el capitulo de herramientas para ACT también habría que mencionar a Fit y Fitnesse, en este caso se trata de un herramienta tipo wiki, se escriben las pruebas en un wiki en un lenguaje más "facil" que html para la gente de negocio y luego las paginas del wiki se ejecutan con código java por detras que toma los datos y los resultados esperados de las paginas del wiki y decide si la prueba pasa o no pasa. (fitnesse por cierto esta desarrollada por Robert Martin con ayuda de alguno de sus hijos xd)
Actualmente no usamos ninguna de estas herramientas, están en la agenda pero de momento no hemos tenido tiempo de ponernos con el tema verdaderamente en serio. Si que hacemos ACT pero simplemente con JUnit, dado que estamos construyendo un framework y las pruebas las definimos y las programamos tecnicos no nos es tan urgente, de momento, tener herramientas que sirván de "puente" entre la gente de negocio y la gente tecnica.
Aunque sin duda lo que me parece un reto de estas herramientas es conseguir que la gente de testing&QA, y de negocio ya ni te digo, se ponga con herramientas de este tipo, que aunque son herramientas "faciles" de manejar y pensadas para que se puedan expresar test de forma natural no son herramientas de "arrastrar y soltar" y exijen mucho esfuerzo para definir las pruebas con precisión (por mucho lenguaje natural que sea nadie te libra de especificar todos los datos de entrada y de salida para cada feature, y esto es un curro y no trivial en casos reales de verdad)
Esto nos lleva a que para usar estar herramientas se exije primero un cambio de mentalidad en la gente encargada del testing que tienen que tomar un papel mucho más activo en los desarrollos, colaborando con los equipos definiendo estos test en lugar de esperar a que el desarrollo este terminado para hacer pruebas manuales de la aplicación.
Un par de apuntes.
Te has dejado el link Erick http://maxheapsize.com/2009/10/13/concordion-vs-cucumber-and-java-based-acceptance-testing/ :)
Y a easyb yo no lo metería en el mismo grupo, porque se mezcla la definición de los test con el código que los ejecutará, por lo que ya se estarían programando los tests. Para mi easyb estaría en el grupo de jUnit, TestNG... en cuanto a que podrían escribir tests de aceptación pero "manchándose las manos" escribiendo código.
Acerca del artículo, hecho de menos que se haga referencia a tests de aceptación a nivel de interfaz de usuario, ya que es lo habitual en la mayoría de desarrollos. En mi caso utilicé alguna vez cucumber con webrat para testear a nivel de interfaz web(en proyectos con RoR). Creo que es una herramienta muy interesante para, a partir de historias de usuario, sacar los test de aceptación y poder ir comprobando si lo que implementas está correcto o si has roto la build con algún cambio posterior.
Me vais a perdonar, pero echandole un ojo por encima a esas dos herramientas, me parece que estan muy bien... en un mundo de fantasia. Las especificaciones practicamente son programas en español, no el algoritmo en si pero si la llamada. Es como un traductor de lenguaje natural a JUnit ¿De verdad esperais que la gente de negocio "programe" las pruebas aunque sea en español? No solo es que en muchos casos se preocupan mas de aspectos visuales como tipos de letra o colores (que, ojo, son muy importantes porque es lo que ve el usuario) es que simplemente piensan distinto. Nosotros esperamos que se piense en un orden logico, primero una cosa, despues otra, para hacer la tercera primero necesito hacer otra cosa antes, etc... Como programando. Mientras que ellos piensan de forma mas anarquica, en plan "me hago un bocadillo" olvidando los pasos de "ir a la cocina", "abrir el frigorifico", "ver si esta vacio", "ir a comprar si lo esta", etc.
¿Creeis que iba a ser util un test escrito en lenguaje natural por alguien que no piensa de una manera homologable a como lo hace una maquina?
Y aunque lo hiciera, ¿cuanto tiempo iba a durar? Porque ya sabeis que andar sobre el agua y programar segun las especificaciones es facil si ambas estan congeladas, pero no es lo normal.
Podria usarse si añadimos una capa mas entre la gente de negocio y los tecnicos, con un departamento entero traduciendo los word y los powerpoint de la gente de negocio a las "features" de esas aplicaciones. Pero cuanta mas gente, mas ruido.
"Es como un traductor de lenguaje natural a JUnit". Esta es la impresión que me ha dado a mi tambien. Me estoy perdiendo algo? Por qué poner otra capa si ya tienes las pruebas JUnit?
Que aporta? Supongo que la posibilidad de que las pruebas se usen como documentación (lo cual es discutible). Pero compensa el trabajo que lleva?
Yo también lo veo un poco Ciencia-Ficción. Si la gente del cliente fuera tan proactiva y competente a nivel técnico en desarrollo de software, todo sería tan fácil que no harían falta esos frameworks.
Yo para las pruebas de aceptación automatizadas uso Selenium lanzado dde Junit (Selenium RC) para webapps y simples mensajes XML lanzados desde soapui con Ant o Manven para webservices. Aunque el primero requiere mucho trabajo y tengo pendiente mirarme algo más ágil.
Bueno, pues os doy mi opinión acerca de lo que decís por haber usado una de estas herramientas, juraría que no vivo en un mundo de fantasía(¿o quizás sí? XD)
La idea no es tener un "traductor", es escribir las historias de usuario en los diferentes escenarios que se definan en lenguaje natural, así todo el mundo lo puede entender(sí, sirve como documentación) y comprobar con la ejecución de tests que el resultado es aceptable a nivel de negocio. Estas historias quizás sí las podría escribir alguien no-técnico(tras un entrenamiento, claro) o un técnico. Después alguien debería programar las precondiciones, la transición y comprobar si el resultado es el correcto.
En mi experiencia, como cualquier herramienta de testing, resultaba muy útil para responder a cambios. Si cambia la especificación, se cambia la historia, se hacen las modificaciones que sean necesarias para testear la "aceptación" y luego el código de la aplicación. Está claro que si no se cambian las historias, no sirve de nada, igual que si no se cambia cualquier tipo de test.
Sobre concordion no puedo hablar, pero para hacer tests de aceptación a nivel de interfaz web con cucumber, se integra con herramientas de testing tipo selenium, webrat, watir...
Escribe tu comentario