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?

4 pensamientos en “Knock, knock … Buenos días developer, venimos a hablarle de TDD

  1. Joaquín Ismael Robles Martínez

    Yo soy un niño melón, y reconozco que no realizo TDD 100%, realmente cuando no practico TDD, es cuando realmente estoy atascado y no se como continuar o empezar. Enlazando con otro post tuyo en el que comentabas que la primera fase era pensar, pues en ocasiones me resulta más facil desarrollar algo (en baby steps) y luego ir realizando la prueba, supongo que será lo mismo que siente un escritor ante un folio en blanco. Aún así , voy haciendo baby steps de código y a posteriori los pasos necesarios para el test,así voy detectando errores aunque realmente pierdo el foco del diseño dirigido por pruebas.

    Por otra parte, me da la sensación que al final no encuentro tanta diferencia entre mi código realizado con TDD y el realizado con pruebas a posteriori del código, supongo que porque de ambas formas no me salto nunca la fase del refactoring y en ambas utilizo baby steps.

  2. Carlos Ble

    Muchas gracias por la mencion Juan Maria 🙂 Acabo de descubrir tu blog gracias a Javier Gutierrez y estoy encantado. Muchos posts que me van a ser de utilidad. Y la traduccion del libro que has hecho pinta muy interesante. Me lo apunto para echarle una lectura en un futuro cercano.

    Felicidades 🙂

  3. juanlao Autor

    Hola Carlos:
    Muchas gracias por tu comentario, espero cualquier feedback que me puedas dar. Javier ya me ha dado mucho también 🙂

Los comentarios están cerrados.