:meetup: Agile Testing: TDD y BDD con Felipe Talavera

este es el hilo de conversacion para este meetup

1 me gusta

aca van las slides!!

1 me gusta

aca va el video!

Hola @diegosep, lo que planteo Hernan Wilkinkson en agiles 2015, es que si se puede, la forma para lograr esto es primero refactorizar tu código utilizando unit test, una vez tu código esta refactorizado aplicas TDD.

1 me gusta

Lo he intentado un par de veces, y he conversado harto con @darsenov que ha hecho esto a escalas importantes.

El asunto es sobre el mantenimiento de aplicaciones legacy (entendiendo como legacy: sin pruebas unitarias).

  1. Cubrir con pruebas de integración los flujos críticos de la aplicación. Estas pruebas deberán interactuar si o si con la interfaz de usuario para poder ejecutar, y serán validados contra outputs en base de datos o archivos o la misma interfaz de usuario. Esto es con el objetivo de que cuando comiences a hacer el refactoring del código, tengas algo de red de seguridad para trabajar.

  2. Cubrir con pruebas unitarias los componentes más importantes de la aplicación hacia afuera. Esto es más complicado de lo que parece, ya que hay que hacer una tonelada de refactoring para desacoplar componentes que nunca fueron programados con intención de ser probados. Generalmente en este punto sea necesario utilizar alguna de las herramientas pagadas de unit testing que permiten hacer fakes o mocks de código sellado, estático o privado (para java, .net y otros lenguajes fuertemente tipados. para lenguajes dinámicos esto es más fácil) El objetivo debiera ser eliminar las pruebas del punto 1 por pruebas de integración un poco más flexibles y rápidas, junto con una suite de pruebas unitarias muy rápidas que tengan buena cobertura sobre las funcionalidades core.

  3. Ya que tienes los componentes separados y probados, puedes comenzar a desarrollar nuevas funcionalidades con TDD e ir refactorizando de apoco el resto de la aplicación y componentes.

Nadie dijo que era fácil.

2 Me gusta

Como comenta @davidlaym, no es simple e inicialmente cuesta mucho que se entienda esta inversión de tiempo, pero cuando pensamos ¿cuánto tiempo nos cuesta modificar un sistema legado?, se justifica plenamente esta inversión. Como dato a la conversación y una herramienta que le comente a @felipet ,utilizar herramientas de cobertura de test ayudan mucho a entender cual es la calidad de nuestro código, una herramienta fácil de usar es EclEmma, es gratuita, se integra con eclipse, esta indica el porcentaje de cobertura general y por clase.

acá el link:

http://eclemma.org/

2 Me gusta

Acabo de encontrar este artículo sobre los problemas de las herramientas BDD. Es un interesante contrapunto, ¿Qué opinan?

http://thoughtworks.github.io/p2/issue12/bdd-dont/

1 me gusta

@davidlaym totalmente de acuerdo con el articulo!

Nadie dijo que era fácil, correcto.
De hecho tengo uno de los módulos más críticos del sistema, en forma legacy (media novedad, diran muchos, pues en la mayoría de los casos los legacy son los que terminan siendo menos tocados porque precisamente “lo que funciona no lo toques” :-/ ).
Estamos aun planeando la estrategia a seguir. Por el momento gana la opción de hacerlo de nuevo.
Creo que es una ventaja el que hacerlo de nuevo sea una estrategia económicamente factible en este caso.
Ahora bien, el set de pruebas que se puedan hacer sobre la versión actual usando jmeter, lo replicaríamos como condiciones de aceptación del modulo nuevo.

Interesante la temática y no es fácil, pero no por eso le vamos a hacer el quite.