UnitTesting como cultura de desarrollo - del dicho al hecho

En el alt.net open space buenos aires del 11 de diciembre del 2010 @jfroma planteó este tema:

UnitTesting como cultura de desarrollo - del dicho al hecho

Experiencias y desafíos de la evangelización al Unit Testing.

Es muy común escuchar a un desarrollador decir; "sé lo que es Unit Testing, entiendo y aprecio el valor agregado que nos da, sé que es bueno.... pero.... pero no lo hago".

  • ¿Cuáles son los obstáculos con los que nos encontramos?
  • ¿Cómo podemos facilitar el camino en nuestros equipos de desarrollo?
  • ¿es verdad que desarrollar con test requiere más tiempo?

Durante la charla en el open space se mencionaron tres tipos de test: test de aceptación, test de integración y test unitarios. En este blog post me referiré a los dos últimos (integración y unitarios). Algunas de las preguntas planteadas fueron:

  • ¿Cómo empezar a hacer testing?
  • ¿Cómo incluir tests a un proyecto heredado (legacy code)?
  • ¿Cómo convencer a quién no hace uso de esta práctica de comenzar a utilizarla?

¿Cómo empezar a hacer testing?

Pienso que lo primero que tenemos que hacer es entender que ventajas nos da el testing, no se trata de escribir test por el simple hecho de hacer testing y menos aún eso significa que vaya a subir la calidad de nuestro desarrollo de por sí, sino que tenemos que entender que ventajas nos da escribir test y a partir de eso decidir (con fundamentos) si lo queremos hacer o no y que tipo de test (por ejemplo, en varios blog post que he publicado código no escribí ningún test).

A mi forma de ver, una de las ventajas de escribir tests es que la funcionalidad que desarrollamos queda asegurada durante el proceso completo de desarrollo del sistema, con esto me refiero a que si yo u otra persona modifica alguna parte de la aplicación que afecta negativamente la funcionalidad que aseguré, vamos a tener una alerta avisándonos de esta situación (y no vamos a depender de que un tester o el mismo usuario encuentre el problema).

Otra ventaja, cuando uno ya está acostumbrado a escribir tests, es que el desarrollo se vuelve mucho más rápido, no es lo mismo desarrollar una funcionalidad ejecutando y probando “a mano” a que lo haga otro programa por nosotros.

El punto anterior también nos permite que cada vez que desarrollamos algo nuevo o modificamos algo existente estemos probando de no romper ninguna de las funcionalidades aseguradas (y dudo que se haga si no hay testing automatizado).

¿En casa de herrero cuchillo de palo?

Con los mismos fundamentos que, por ejemplo, un banco decide utilizar un sistema para procesar millones de transacciones (velocidad, seguridad en el proceso, reducción del error humano, etc.) es que nosotros podemos elegir utilizar un sistema para probar nuestros desarrollos (velocidad, seguridad en el proceso, reducción del error humano, etc.).

¿Cómo incluir tests a un proyecto heredado (legacy code)?

Ya sea un proyecto heredado o un proyecto en el que trabajamos nosotros pero no hicimos tests creo que el concepto es el mismo, se trata de asegurar funcionalidad.

En estos casos lo más complicado no suele ser pensar los test sino que es muy probable que la aplicación no haya sido pensada en ser testeable, por ejemplo:

  • que no se haya usado inyección de dependencias, lo que va a dificultar emular determinados componentes del sistema para inducir errores, evitar dependencia a los datos, etc.,
  • que la lógica de negocio esté distribuida en distintas capas, incluyendo el frontend,
  • que se dependa de los datos cargados en la base de datos y a su vez que los datos actuales no sean 100% consistentes porque “son datos viejos”,
  • que se usen sistemas externos o dispositivos directamente desde la lógica de negocio sin la opción de emular dichos dispositivos.

Ante este escenario no es imposible escribir test, pero va a ser necesario algunos ajustes y reestructuraciones del código donde destaco dos tipos de test:

  • Test para asegurar funcionalidades existentes
  • Test que aseguren el nuevo trabajo

Test para asegurar funcionalidades existentes

Sobre todo pensando en la funcionalidad crítica, quizás queramos asegurarnos que, por ejemplo, nuestro en sistema de transacciones bancarias nunca dejen de andar las transferencias aunque si dejase de funcionar un reporte de bajas de cuentas podría ser menos crítico (esto no quiere decir que no sea relevante el reporte sino que no va a rodar la cabeza de nadie por que deje de funcionar dicho reporte).

Una forma de hacer test de esto es a caja cerrada (o caja negra), donde probamos la funcionalidad midiendo los resultados y no cómo lo hace, para esto es necesario conocer bien el negocio y no así la codificación (quizás si no se conoce el código es mejor aún). Este tipo de tests se pueden diseñar con los equipos de QA o con los funcionales donde ellos ayuden a pensar los test y los desarrolladores a codificarlos.

Test que aseguren el nuevo trabajo

Ya sean nuevas funcionalidades, modificaciones, corrección de bugs, etc., vamos a querer que los siguientes pasos que se den sean firmes, que no se vuelva a romper lo mismo (por un mínimo de amor propio aunque sea). Para esto vamos a tener que escribir los test y, como dije antes entre las ventajas de tener test, vamos a asegurar la funcionalidad. El equilibro a buscar en esta tarea va a ser cuanto hay que modificar el código existente para que la modificación o nueva funcionalidad sea testeable.

¿Cómo convencer a quién no hace uso de esta práctica de comenzar a utilizarla?

Respecto a este tema, creo que las opiniones de @martinsalias y @carlospeix fueron las más aceptadas y se trata de mostrar resultados y evidenciar cuando la existencia de un test hace evitable un mal momento como por ejemplo “nos evite tener que trabajar un fin de semana”.

Complementos del testing

Todo esto que conversamos, sumado a entornos de integración continua, deploy automatizado para testing ¿todas las noches?, y una buena conducta de: “un issue <-> un commit” creo que da una base sólida para empezar a hablar de calidad en el desarrollo (pero es solo la base).

Links

Blog post de Pedro respecto al open space: http://pedrowood.wordpress.com/2010/12/21/alt-net-open-space-buenos-aires-2010/

Sitio de la comunidad: http://altnethispano.org

No hay comentarios.:

Publicar un comentario