TDD y la premisa de "Agregar valor"

Descubrir lo que aporta un valor

Sólo hay 2 tipos de código: el que aporta valor al cliente y el que no. Yo los llamo el código de dominio y el código de plomería. Pero ¿qué significa esto?

Código de dominio

En términos simples si no es en la jerga de negocios, no es código de dominio. Es decir, todos los conceptos de negocio y las reglas que dictan cómo se relacionan entre sí, los servicios proporcionados por la empresa a sus clientes, las acciones en situaciones específicas (procedimientos) que son parte del dominio del negocio y la automatización de estos (completo o parcial) son las cosas que ayudan a la empresa a incrementar ingresos, disminuir costos, acelerar la ejecución de procedimientos y tomar mejores decisiones. De lo contrario no añade valor al negocio.

Código de plomería

Este es el tipo de código que directamente no agrega valor al negocio. Está compuesto sobre todo por aspectos técnicos como la base de datos, arquitectura de software, el stack de tecnología, frameworks, etc. Es necesario en un sistema de información, pero no es la razón por la qué el sistema fue creado en primer lugar.

La paradoja del “huevo o la gallina”

El sentido común dicta que las cosas que son más importantes para el negocio deben ponerse primero. Eso es, un equipo de desarrollo debe asegurarse que las políticas, reglas y lógica se apliquen correctamente en el código antes que nada. La práctica común, es una historia diferente. Eso es porque el desarrollador necesita generalmente una cantidad mínima de código de plomería para probar si una regla de negocio está funcionando como se esperaba. Consideremos el caso cuando un desarrollador tiene que probar una regla simple: no puede obtener más dinero de una cuenta que el disponible. Para probar esto el desarrollador puede empezar a crear una tabla BankAccount, luego escribir el código para la regla, luego crear un programa de prueba para ejercitar ese código. Y entonces él tendría que agregar código para el manejo en caso de falla con la conexión de base de datos. Así que escribir el código que agrega valor (código) es sólo una pequeña fracción de toda la operación. La mayoría de las acciones son sobre la configuración de la infraestructura. Más aún, muchos de los desarrolladores toman esto hasta crear una API o interfaz de usuario. Esto hace más difícil probar el código relacionado con la regla, puesto que ahora hay varios puntos donde algo puede ir mal. Ahora para saber si la regla se implementa correctamente, el desarrollador tiene que poner una aplicación de extremo a extremo que tendrá que ser modificada en caso de que el código deba reescribirse. ¿Que es primero: dominio o código de plomería? 

Definir lo que hay que hacer

TDD cambiar el enfoque del código de plomería al código de dominio. Lo hace al obligar a los desarrolladores a crear especificaciones funcionales en forma de pruebas y crear código para cumplir con las expectativas de la especificación.

En un proyecto de desarrollo típico, mucho del análisis inicial entra el código de plomería: base de datos, estructuras, sistemas operativos, hardware y así sucesivamente. Por otro lado, la idea de negocio de lo que el sistema se supone que hace esta sujeto a evolucionar tan pronto como los desarrolladores y el negocio empiecen descubrir los requerimientos y necesidades. Por desgracia, muchos desarrolladores no cavan mas en esto hasta más tarde cuando se ha decidido todo el stack de tecnología. Esto crea una situación donde el código de dominio ahora está restringido por las limitaciones del stack de tecnología.

TDD invierte esta situación. Al contar con los desarrolladores para crear las especificaciones en primer lugar, se encuentran en la necesidad de entender mejor cual es el resultado esperado para una pieza de software. Tomando nuevamente el ejemplo anterior, ¿qué se supone que debe suceder cuando en la cuenta bancaria no hay suficiente dinero para cumplir con una operación de retiro? ¿Una excepción? ¿Devuelve un mensaje? ¿Pueden ser una cadena o una estructura de clases? ¿O una función (closure)?¿Debe indicarse al titular de la cuenta ir a través de algún tipo de procedimiento (como préstamo)? Para responder a estas preguntas, el desarrollador debe entender lo que espera el negocio. Esto lo llevará a volver al negocio y hacer preguntas hasta que entienda lo suficiente como para continuar. Este proceso generalmente ocurre en cualquier proyecto de desarrollo, especialmente si está siguiendo una metodología ágil, pero el uso de TDD lo acelera grandemente. Permite al equipo de desarrollo no sólo para escribir el software de la manera correcta, sino ayudar a la empresa para decidir si es lo correcto.

Así que ¿estás listo para empezar?