TDD, BDD & Test de aceptación

5
25727

TDD, BDD & Test de Aceptación

0. Índice de contenidos.

  1. Introducción
  2. TDD
  3. BDD
  4. Test de Aceptación
  5. Conclusiones
  6. Saber Más.

1. Introducción

Este tutorial está enfocado a hacer un repaso por dos de las técnicas de desarrollo ágil más extendidas en la actualidad: TDD ( Test Driven Development ) y BDD ( Behaviour Driven Development ), las cuales tienen un fin común, mejorar la calidad del software producido.
Además queremos ir un paso más allá de los Test Unitarios y de Integración que suelen ir ligados a TDD/BDD y hacemos un breve repaso de las diferentes posibilidades a la hora de integrar los test de aceptación dentro de nuestro ciclo de pruebas de una manera lo menos dolorosa y costosa posible.

2. TDD

Desarrollo guiado por pruebas o TDD es una técnica de programación que se centra en el hecho de que las pruebas las escribes antes de programar la funcionalidad, siguiendo el ciclo falla, pasa, refactoriza [ red, green, refactor ] intentando así mejorar la calidad del software que producimos.

Son muchos los beneficios que nos aporta seguir correctamente las ideas de TDD, entre otras podemos destacar:

  • Nos ayuda a pensar en como queremos desarrollar la funcionalidad.

  • Puede hacer software más modular y flexible.

  • Minimiza la necesidad de un “debugger”.

  • Aumenta la confianza del desarrollador a la hora de introducir cambios en la aplicación.

Pero como todo también tiene sus fallos, ya sea por no entender bien la filosofía, o por querer llevarla a un extremo, algunos de los problemas que tiene TDD son:

  • Dificultades a la hora de probar situaciones en las que son necesarios test funcionales o de integración, como pueden ser Bases de Datos o Interfaces de Usuario.

  • A veces se crean test innecesarios que provocan una falsa sensación de seguridad, cuando en realidad no están probando más que el hecho de que un método haga lo que dice que hace.

  • Los test también hay que mantenerlos a la vez que se mantiene el código, lo cual genera un trabajo extra.

  • Es difícil introducir TDD en proyectos que no han sido desarrollados desde el principio con TDD.

  • Para que sea realmente efectiva hace falta que todo el equipo de desarrollo haga TDD.

  • A veces el desarrollador se centra más en como construir una funcionalidad que en preguntarse si la funcionalidad es de verdad necesaria para el usuario o es como la quería el usuario.

Para intentar solucionar algunos de estos problemas nace BDD y se usan otras técnicas como los Test de Aceptación.

3. BDD

El Desarrollo Guiado por el Comportamiento o BDD es un proceso que amplia las ideas de TDD y las combina con otras ideas de diseño de software y análisis de negocio para proporcionar un proceso ( y una serie de herramientas ) a los desarrolladores, con la intención de mejorar el desarrollo del software, BDD se basa en TDD formalizando las mejores practicas de TDD, clarificando cuales son y haciendo énfasis en ellas.

En BDD no probamos solo unidades o clases, probamos escenarios y el comportamiento de las clases a la hora de cumplir dichos escenarios, los cuales pueden estar compuestos de varias clases,

Algunos de los hábitos que fomenta BDD, añadiéndose a los que aporta TDD son:

  • Nos ayuda a centrarnos en lo que es verdaderamente importante para el ‘negocio’
  • Si generamos las pruebas con un lenguaje concreto, nos pueden servir a la hora de hacer los test de Aceptación

A la hora de llevar a la practica BDD es muy recomendable usar un DSL que nos ofrece un lenguaje común sobre el que poder hacer los test y así disminuir la fricción a la hora de compartir los test.

Los DSL’s más usados a la hora de definir escenarios en BDD suelen constar de Steps o pasos, se suelen dividir en:

  1. Dado: los pasos necesarios para poner al sistema en el estado que se desea probar
  2. Cuando: La interacción del usuario que acciona la funcionalidad que deseamos testear.
  3. Entonces: En este paso vamos a observar los cambios en el sistema y ver si son los deseados.

Usar un DSL en vez de un lenguaje natural a la hora de especificar nos puede ayudar a mantener el mismo nivel de abstracción a la hora de definir los escenarios, un buen DSL es flexible y potente una vez todos los miembros de una organización lo conocen y usan.

Todo esto nos sirve para comprobar el comportamiento interno de la aplicación, una vez esté la funcionalidad hecha, queremos saber si es lo que buscaba realmente el usuario, para ello existen los test de aceptación.

4. Test de aceptación

Los test de aceptación son aquellos destinados a determinar si los requisitos de cierta funcionalidad han sido cumplidos, como usuarios finales, no tienen porqué preocuparse por los detalles de la implementación, sino que deberían poder centrarse más en que la parte funcional cumple las expectativas creadas al inicio del Sprint.

Los DSL’s y las practicas de BDD nos otorgan ese punto extra de abstracción a la hora de especificar las historias, además de servirnos de documentación de los avances y logros de cada Sprint,

Los test de aceptación plantean una serie de problemas técnicos, entre ellos se pueden destacar los siguientes:

  • Problemas a la hora de automatizar dichos test.

  • En caso de no usar un lenguaje muy concreto pueden encontrarse problemas a la hora de compartir los test.

A la hora de automatizar los test de aceptación existen diferentes herramientas que cumplen con esa función que no entran dentro de la finalidad de este tutorial.

La automatización de pruebas de aceptación suele llevar consigo una serie de problemas asociados:

  • Hacer los test es costoso a nivel de recursos ( tiempo / dinero ).
  • No toleran bien los cambios tanto en la especificación como en la implementación.
  • Dificultades a la hora de reconstruir los escenarios de pruebas.

Por eso es muy útil el uso de herramientas como pueden ser TestLink o TestRails, que nos permitan documentar y organizar todos los Test que tenga nuestra aplicación, y ordenarlos tanto por Sprint como por versión de nuestra aplicación.

Aquí el uso de un DSL resulta casi imprescindible, ya que la libertad del lenguaje natural dificulta mucho la especificación de los test de aceptación que más adelante tendrá que realizar el usuario, ya sea por usar un lenguaje muy técnico o por seleccionar un nivel de abstracción incorrecto a la hora de declarar estas pruebas.

En las siguientes imágenes podemos ver como declaramos un Test de Aceptación usando la notación que nos ofrece Gherkin incluyéndolo a través de la aplicación Testlink

TestLink01

En la siguiente captura podemos ver el control de los test totales que hay probando esa característica ( teniendo en cuenta los diferentes escenarios ), los test que han pasado ( verde ) y los test que han fallado ( rojo ).

TestLink02

En las siguientes imágenes podemos observar como quedaría si en vez de usar un DSL usásemos el lenguaje natural:

TestLink02
TestLink02

En este sencillo caso, podemos observar que si no definimos una serie de pasos en un lenguaje fijado, a la persona que escriba los escenarios, se le podrían olvidar pasos importantes, en este caso, el usuario estaría dando por hecho algunas cosas que podrían generar errores de interpretación, este tipo de errores se verían agravados en casos más complejos como los que podemos encontrarnos en cualquier aplicación del mundo real.

5. Conclusiones

Como hemos podido ver BDD coge las mejores practicas de TDD e intenta guiar al desarrollador a la hora de elegir que piezas de la aplicación probar, eso sumado a los test de aceptación puede ayudarnos a priorizar el desarrollo de las historias que realmente le aportan valor al usuario.

El hecho de tener las pruebas escritas con un DSL y que estén catalogadas en una herramienta como pueda ser TestLink, nos permite tener un control bastante preciso sobre la calidad del software que estamos produciendo.

6. Saber Más

Si quieres saber más puedes visitar alguno de los siguientes enlaces:

5 Comentarios

  1. Muy buen tutorial para la gente que quiera iniciarse en TDD/BDD y aclarar conceptos fundamentales.
    He visto una errata: donde pone \\\”falla, pasa, refactoriza [ green, red, refactor ]\\\”, debería poner \\\”\\\”falla, pasa, refactoriza [ red, green, refactor ]\\\”

Dejar respuesta

Please enter your comment!
Please enter your name here