Estoy leyendo ahora en mis ratos perdidos de tren al trabajo el libro Test Driven: TDD and Acceptance TDD for Java Developers. Los dos primeros capítulos me han resultado muy pesados porque no paran de repetir una y otra vez las ventajas de TDD de mil formas distintas, ventajas por otra parte ya bastante conocidas. Pero acabo de entrar en la parte donde se va desarrollando código con TDD y me está pareciendo interesante.
Una de las cosas que me ha llamado la atención es lo de la "triangulación" con TDD. Ya había leído de ella sin llegar a entenderla realmente, simplemente porque los ejemplos que había leído de triangulación eran muy tontos. Por ejemplo, si tienes que hacer un test de una clase que suma, el primer test podría ser el típico
assertEquals(4, sumador.suma(2,2));
Explicando la triangulación te dicen que pongas directamente que ese método suma(2,2) devuelve a piñón fijo 4 y luego, triangulando, haces otro ejempo de suma, por ejemplo, suma (2,5) y así llegas a la implementación correcta return sum1+sum2. Como se puede ver, algo un poco "estúpido".
Este libro menciona la triangulación varias veces, pero en un párrafo deja muy claro qué es exactamente o, al menos, así me lo ha parecido a mí. El ejemplo que comenta es que queremos tratar varias tipos de tarjetas de crédito (visa, master card, dinners club, etc, etc). El problema es que cada tarjeta tiene sus particularidades y que podemos no tener muy claro cómo hacer el código para tratar todas esas particularidades, qué partes van a ser comunes y ponernos a pensar a priori todo ese código puede ser tedioso.
Así que la solución es la famosa triangulación. Cogemos una de las tarjetas y empezamos el TDD con ella, los test, el código, específico para esa tarjeta, sin preocuparnos de las otras y finalmente el refactoring. Luego cogemos la segunda, hacemos nuevos test para esa y modificamos el código para que funcione para las dos. En la parte importante de refactoring es donde realmente arreglamos ese código para que las partes comunes y no comunes queden bien diseñadas para esas dos tarjetas. Luego tercera tarjeta, más test, más tocar código y lo más importante, nuevamente refactoring para que el diseño sea lo más claro y mejor posible para tres tarjetas.
De esta forma, deberíamos llegar a una de los mejores diseños posibles para tratar los tipos de tarjeta que debemos tratar.
Así que cuando hacemos TDD, más que triangular siempre a piñón fijo, incluso para suma(2,2) haciendo que devuelva 4 a piñón fijo y obligarnos a hacer otro test suma(2,5), debemos aplicar triangulación cuando tenemos varios casos similares pero con peculiaridades cada uno de ellos y no tenemos muy claro cómo hacer un código elegante o el mejor diseño para tratar esas particularidades a priori.