TDD: Outside-In vs Inside-Out

2
9087

En este tutorial comentamos dos corrientes a la hora de enfocar el diseño guiado por test o TDD.

Ya hemos hablado con anterioridad de la importancia de realizar nuestros desarrollos siguiendo el mantra del TDD (como se puede comprobar aquí), conocemos por tanto sus virtudes, las garantías que nos ofrece y que, algunos, consideramos imprescindibles en nuestro día a día. Sin embargo, una faceta menos conocida del TDD son sus distintas escuelas o maneras de enfocar los problemas a la hora de resolverlos.

En este tutorial trataremos de presentar esas escuelas y sus principales características para así añadirlas a nuestra «caja de herramientas».

Índice de contenidos

1. Introducción

Dos son las principales vertientes que vamos a presentar en este tutorial: la Escuela Clásica y la escuela de Londres.

La escuela clásica toma su nombre por representar el concepto original definido en libros como «Test-driven Development By Example» de Kent Beck, y que se distingue por enfatizar la práctica de la «triangulación«, que explicaremos más en profundidad con posterioridad.

La escuela de Londres toma su nombre debido a que tiene su base, principalmente, en el libro «Growing Object Oriented Software Guide By Test» de Stephen Freeman y Nat Pryce, enfatizando los roles, responsabilidades e interacciones.

A continuación bajaremos más al detalle en cada una de ellas:

2. Escuela Clásica (Inside-Out)

La escuela clásica se distingue por centrarse en la verificación del estado de los objetos, siendo por ello imprescindible que el contexto de los test siempre deba estar formado por «objetos reales«, configurados previamente. Para la correcta generación de estos contextos se pueden crear clases que nos ayuden, por ejemplo a través de los denominados «MotherObjects» o implementaciones del patrón «Factory«.

La existencia previa de estos «objetos reales«, implica que el diseño de nuestra solución irá creciendo poco a poco desde la base hasta la funcionalidad final. De ahí el sobrenombre de técnica Inside-out.

Otra de las características más distintivas de este enfoque es la triangulación. El concepto se basa en obtener 2 o más casos similares antes de proceder con la implementación de una solución genérica.

Test_TDD_triangulacion-02

Pongamos por caso que, en una aplicación que estamos desarrollando, necesitamos tratar con múltiples proveedores de información, todos ellos similares, aunque cada uno de ellos mantiene una serie de particularidades. Los pasos serían los siguientes:

  • El primer paso sería realizar la implementación concreta para un único proveedor, obviando el hecho de que existen más proveedores.
  • El segundo paso sería realizar la implementación para el segundo proveedor.
  • Por último, realizaríamos la generalización de la solución para los N casos puesto que en los dos casos implementados deberían poder observarse puntos en los que realmente pueden establecerse generalizaciones. En caso de no observar las suficientes similitudes, siempre se puede continuar implementando soluciones hasta observar las similitudes.

3. Escuela de Londres (Outside-In)

La escuela de Londres toma un enfoque distinto, centrándose en verificar que el comportamiento de los objetos es el esperado. Dado que este el objetivo final, verificar las correctas interacciones entre objetos, y no el estado en sí mismo de los objetos, mediante este enfoque podremos ahorrarnos todo el trabajo con los objetos reales (creación y mantenimiento) sustituyéndolos por dobles de test.

Siendo este el caso, podremos empezar por la funcionalidad final que se necesita, implementando poco a poco toda la estructura que dé soporte a dicha funcionalidad. Por esto, esta técnica recibe el nombre de Outside-in, en este caso, desarrollando las funcionalidades desde el exterior hacia dentro.

También es importante remarcar el uso de la técnica del doble bucle:

  • Comenzaremos por un test de aceptación que falle, lo que nos guiará al bucle interno.
  • En el bucle interno, que representa la metodología de trabajo TDD («Red-Green-Refactor»), implementaremos la lógica de nuestra solución.
  • Realizaremos las iteraciones necesarias de este bucle interno hasta conseguir pasar el test de aceptación.

Test_TDD_bucle

4. Conclusiones

Motivaciones o gustos personales aparte, ambas técnicas son increíblemente útiles a la hora de desarrollar, siempre que se utilicen en el momento adecuado.

¿Cuándo guiarnos por la Escuela Clásica?

  • Cuando se quiera verificar el estado de los objetos.
  • Cuando las colaboraciones entre objetos son sencillas.
  • Si no se quiere acoplar la implementación a los test.
  • Si se prefiere no pensar en la implementación mientras se escriben los test.

¿Cuándo guiarnos por la Escuela de Londres?

  • Cuando se quiera verificar el comportamiento de los objetos.
  • Cuando las colaboraciones entre objetos sean complejas.
  • Si no importa acoplar la implementación a los test.
  • Si se prefiere pensar en la implementación mientras se escriben los test.

5. Referencias

  • The London School of Test Driven Development. Emily Bache.
  • Classic TDD or «London School»?. Jason Gorman.
  • Kent Beck, Test-Driven Development By Example, 2003, Pearson Education Inc.
  • Steve Freeman y Nat Pryce, Growing Object-Oriented Software, Guided By Tests, 2010, Pearson Education Inc.

2 COMENTARIOS

DEJA UNA RESPUESTA

Por favor ingrese su comentario!

He leído y acepto la política de privacidad

Por favor ingrese su nombre aquí

Información básica acerca de la protección de datos

  • Responsable:
  • Finalidad:
  • Legitimación:
  • Destinatarios:
  • Derechos:
  • Más información: Puedes ampliar información acerca de la protección de datos en el siguiente enlace:política de privacidad