No todos los TDD son iguales

Hay dos estilos principales de TDD con diferencias significativas entre ellos, cuando se trata de diseño.

Clasicista

El enfoque clasicista es el enfoque original de TDD creado por Kent Beck.

Características principales

  • El diseño se hace durante la fase de refactorización.
  • Normalmente las pruebas son pruebas basadas en entrada y salida
  • Durante la fase de refactorización, la unidad bajo prueba puede crecer a múltiples colaboradores (no simulados).
  • Las simulaciones rara vez se utilizan, a menos que se aíslan los sistemas externos.
  • No se hacen consideraciones de diseño por adelantado.
  • El diseño emerge completamente del código.
  • Es una excelente manera de evitar la ingeniería excesiva.
  • Más fácil de entender y adoptar debido a las pruebas de estados y sin diseño inicial.
  • A menudo se utiliza junto con las 4 reglas del diseño simple.
  • Es bueno para la exploración, cuando sabemos cuál es la entrada y la salida deseada pero no sabemos realmente cómo se ve la implementación.
  • Ideal para casos en los que no podemos confiar en un experto en dominios o en un idioma de dominio (transformación de datos, algoritmos, etc.)

De fuera hacia dentro

Outside-In TDD, también conocida como mockist, es un estilo TDD desarrollado y adoptado por algunos de los primeros practicantes de XP. Más tarde inspiró la creación de BDD.

Características principales

  • A diferencia del clasicista, Outside-In TDD prescribe una dirección en la cual comenzamos a probar nuestro código: desde afuera (primera clase para recibir una solicitud externa) hacia adentro (clases que contendrán piezas de comportamiento únicas que satisfacen la característica implementado).
  • Normalmente, comenzamos con una prueba de aceptación que verifica si la característica en su conjunto funciona.La prueba de aceptación también sirve como guía para la implementación.
  • Con una prueba de aceptación fallida que informa por qué la función aún no está completa (no se devolvieron datos, no se envió ningún mensaje a una cola, no se almacenaron datos en una base de datos, etc.), comenzamos a escribir pruebas unitarias.
  • La primera clase que se prueba es la clase que maneja una solicitud externa (un controlador, un detector de colas, un controlador de eventos, el punto de entrada para un componente, etc.)
  • Como ya sabemos que no construiremos la aplicación completa en una sola clase, hacemos algunas suposiciones de qué tipo de colaboradores necesitará la clase bajo prueba.
  • Los colaboradores se identifican de acuerdo con todas las cosas que la clase bajo prueba debe hacer cuando se invoca su método público.
  • Los nombres y métodos de los colaboradores deben provenir del idioma del dominio (sustantivos y verbos).
  • Una vez que se prueba una clase, seleccionamos el primer colaborador (que se creó sin implementación) y evaluamos su comportamiento, siguiendo el mismo enfoque que usamos para la clase anterior. Esta es la razón por la que llamamos de afuera hacia adentro: comenzamos desde las clases que están más cerca de la entrada del sistema (afuera) y avanzamos hacia el interior de nuestra aplicación a medida que se identifican más colaboradores.
  • El diseño comienza en la fase roja, mientras se escriben las pruebas.
  • Las pruebas son sobre colaboración y comportamiento, no de estado.
  • El diseño es refinado durante la fase de refactorización.
  • Cada colaborador y sus métodos públicos siempre se crean para servir a una clase de cliente existente, haciendo que el código se lea muy bien.
  • Las fases de refactorización son mucho más pequeñas, en comparación con el enfoque clasicista.
  • Promueve una mejor encapsulación ya que ningún estado está expuesto solo para fines de prueba,
    Más alineado con el tell, no preguntes enfoque.
  • Más alineado con las ideas originales de Programación Orientada a Objetos: las pruebas se refieren a los objetos que envían mensajes a otros objetos en lugar de verificar su estado.
  • Adecuado para aplicaciones comerciales, donde los nombres y los verbos se pueden extraer de las historias de usuario y los criterios de aceptación.

Share

Share on facebook
Share on twitter
Share on linkedin

Related Posts

¿Quieres recibir más información sobre tendencias en desarrollo de software, DevOps, innovación o productividad?

Últimas entradas

Aplicaciones Reales con Blockchain

Blockchain es una de las tecnologías que más fama ha adquirido en años recientes; en parte por la explosión de las criptomonedas, pero también por la

¿Qué es refactoring?

El objetivo del refactoring es evitar la deuda técnica que se acumula en el código fuente y  generar un código mas limpio y mas fácil