Knock, knock … Buenos días developer, venimos a hablarle de TDD

Aviso: Este es un post que te va a vender TDD.

En otras publicaciones han resumido las bonanzas de TDD, como el libro de @carlosble “Diseño ágil con TDD“. Os lo recomiendo desde ya.

Pero he encontrado una presentación de Francesco Carucci, antiguo desarrollador de Crytek que actualmente trabaja en Apple, en la que muestra/vende TDD desde el punto de vista del desarrollo de video juegos.

Me ha parecido muy bien estructurada y cómo vende TDD, así que lo pongo aquí para escribirlo, compartirlo y de manera egoísta, como un ejercicio para que me ayude a no olvidar algunas cosas.

La estructura consiste en poner las diferentes razones y excusas que solemos dar para no escribir tests o por qué no hacer TDD y las respuestas que deberíamos grabarnos como mantras. Así que allá vamos:

No hago Tests por que …

… el tiempo que gasto en escribir test es tiempo que podía estar escribiendo código.

• Al final gastamos más tiempo en debugear y mantener código que escribiéndolo.
• Si escribimos primero los test y el código que los pasa, el código que los pasa es código de producción. La consecuencia es que tardamos menos tiempo en tener código que funciona, esto es: código de producción.
• La modificación del código es más confiable. Cuando modificamos código lo hacemos “más tranquilos” ya que sabemos que vamos a romper pocas cosas, y si se rompen, nos vamos a dar cuenta rápido.
• Se evitan bugs de regresión. Al detectar un bug, escribimos un test que lo reproduzca y ese bug no volverá a aparecer.
• Se detectan antes los bugs, como ya vimos en el post anterior

… los test no lo pueden probar todo

• Un test es mejor que ninguno.
• El código legacy o de terceros no hay que testearlo a menos que tengamos que modificarlo.
• Roma no se construyó en un día, pero se construyó (y conquisto el mundo conocido)

… este código es temporal y lo cambiaré después, no necesito testearlo

• Todo el código se modifica tarde o temprano. Hacer código que sea fácil de cambiar es la razón fundamental de TDD: elimina la sobre-ingeniería (KISS, Keep It Simple, Stupid!)
• Los requisitos cambian: entonces hay que modificar los tests afectados y el código de producción. Pero como está testeado unitariamente, el código está más desacoplado, es más fácil de modificar y los cambios tendrán menos efectos secundarios.

En el mundo del desarrollo de juegos

El desarrollo de juegos es diferente: los test automatizados pueden no funcionar.

• En general el desarrollo de juegos es totalmente diferente …
• … pero escribir código es lo mismo, incluso más simple.
• El código de un juego es más algoritmia y matemáticas, eso es incluso más fácil de testear que un proceso de negocio.
• Un código de sobresaliente es lo mismo tanto en un juego como en una web.
• El código de un juego cambia a menudo: más cambios es un motivo más para tener test que comprueben que no se ha roto nada.

Los juegos son para divertirse, un test no puede comprobar que un juego sea divertido.

• Pero sí puedes capturar bugs, y menos tiempo debugando errores significa más tiempo para implementar la parte divertida.
• Crear un test para un bug te asegura que ese bug no volverá a aparecer (El 30% de las correcciones de bugs crean nuevos bugs debido a efectos colaterales)

Esto es un juego AAA, es muy arriesgado hacer test automatizados sobre él.

• Los juegos AAA son muy complejos, muy tecnológicos y muy divertidos. Para conseguir un juego AAA, se deben usar herramientas adecuadas, y los test automatizados son una de esas herramientas.
• Lo arriesgado es NO hacer test en un juego AAA

¿Cuándo TDD no es apropiado?

• Prototipos. Mientras buscamos/probamos posibles soluciones a un problema.
  • La solución final SÍ debe estar hecha con TDD.
• En el código de wrappers de librerías existentes.
• En la capa GUI, eso no es testing unitario, es testing de integración.
• En código de bajo nivel, el que está muy cerca del hardware

Objetivo: Producir más funcionalidades en menos tiempo.

No perdamos de vista el objetivo, producir lo antes posible código que vaya a producción, esto es código que funciona, libre de bugs y mantenible

¿Y tu porqué no haces Test o TDD?