Introducción

El desarrollo basado en pruebas es un método eficaz para garantizar un código bien probado y refactorizable. La idea básica es comenzar el desarrollo escribiendo pruebas. Estas pruebas documentan claramente las expectativas y crean una rúbrica para una implementación exitosa. Cuando se hace correctamente, puede definir claramente la entrada/salida esperada de una función antes de escribir cualquier código. Esto tiene algunos beneficios inmediatos:

• Consideras cuidadosamente la interfaz para interactuar con tu código y la diseñas para que sea comprobable
• Cuando comienzas a escribir código, tu flujo no se ve interrumpido por pruebas manuales o por la lógica de ejecución para predecir el resultado. En lugar de eso, simplemente ejecuta las pruebas
• Aprobar una prueba se convierte en una meta satisfactoria de alcanzar. Dividir el proceso en una serie de hitos bien definidos y alcanzables hace que el trabajo sea más agradable
• Evite la pereza posterior a la implementación y el exceso de confianza que podrían impedirle probar su código

Ahora que estás convencido de los beneficios, puedes comenzar con el desarrollo basado en pruebas (TDD) siguiendo estos pasos:

1. Escribir o modificar pruebas
2. Comprueba si la prueba falla
3. Escribe la cantidad mínima de código para que las pruebas pasen

Estos pasos se siguen en un ciclo, por lo que siempre se agregan más pruebas para desafiar la implementación actual.

El último paso, que especifica escribir la cantidad mínima de código, es donde las cosas pueden volverse tediosas si se siguen estrictamente. Es importante comprender por qué existe esta regla antes de poder determinar cuándo es apropiado desviarse de ella.

Ejemplo sencillo

Tienes la tarea de implementar la función Add(x, y int) int. Antes de pasar a la implementación y simplemente devolver x y, escriba la prueba más simple: 1 1 == 2. Entonces, ¿cuál es la implementación más simple que pasaría la prueba? Es solo el retorno 2. ¡Ahora tus pruebas pasan!

En este punto, te das cuenta de que necesitas más pruebas, así que aceleras el ritmo y agregas algunas más:

• 1 2 == 3
• 100 5 == 105

Ahora tus pruebas fallan, por lo que necesitas arreglar la implementación. Esta vez no puedes simplemente devolver 3 o 105, por lo que necesitas encontrar una solución que funcione para todas las pruebas. Esto lleva a la implementación: return x y.

Si bien esto parece demasiado tedioso en el ejemplo trivial, el estricto cumplimiento de este método hizo que escribieras varias pruebas en lugar de simplemente confiar en tu implementación. Por supuesto, su idea inicial de devolver x y habría funcionado, pero el punto es volver a capacitarse para confiar en las pruebas en lugar de en su propia comprensión del código. En el mundo real, usted no es el único que trabaja en este fragmento de código e inevitablemente olvidará los detalles de implementación. Este proceso te obliga a escribir más pruebas y pensar en más formas de romper la implementación simple.

Con el tiempo, ganarás experiencia y aprenderás a encontrar el equilibrio que funcione en los diferentes escenarios que encuentres. Volverá a la implementación de funciones a toda velocidad y descubrirá que tiene menos errores y escribe más código que se puede mantener.

TDD paso a paso para una API HTTP

Vayamos a un ejemplo más complicado usando TDD para una API REST HTTP. Esta guía paso a paso utiliza mi marco Go, babyapi, pero los conceptos se pueden aplicar en cualquier lugar.

babyapi usa genéricos para crear una API CRUD completa en torno a estructuras Go, lo que hace que sea muy fácil crear una API REST completa y una CLI de cliente. Además de esto, el paquete babytest proporciona algunas herramientas para crear pruebas de tablas API de un extremo a otro. El uso de TDD a nivel de API permite probar completamente las capas HTTP y de almacenamiento de una nueva API o función, todo a la vez.

Descargo de responsabilidad: dado que babyapi maneja la mayor parte de la implementación y también se utiliza para generar texto estándar de prueba, técnicamente no estamos comenzando con TDD. Sin embargo, veremos qué tan beneficioso es agregar soporte para solicitudes de PATCH a nuestra API.

1. Crear un nuevo proyecto Go
   

2. Crea main.go inicial usando el ejemplo simple de babyapi
   

3. Utilice la CLI para generar un texto estándar de prueba
   

4. Implemente cada prueba completando los marcadores de posición con el JSON esperado
   

5. ¡Ejecute las pruebas y compruebe que pasan!

6. Dado que PUT es idempotente, requiere que se incluyan todos los campos. Para evitar esto, queremos agregar soporte para alternar Completado con solicitudes PATCH. Comenzamos agregando una prueba simple de cómo esperamos que se vea esta característica
   

7. Esta prueba falla porque babyapi no admite PATCH de forma predeterminada. Podemos solucionarlo implementando Patch para la estructura TODO. Dado que definimos nuestra función con dos pruebas, nuestra implementación más simple no es solo configurar Completado = verdadero y tenemos que usar el valor de la solicitud
   

8. Ahora podemos cambiar el estado Completado de un TODO, pero aún no podemos usar PATCH para modificar otros campos como lo muestra este nuevo conjunto de pruebas
   

9. Actualizar parche para configurar los campos restantes
   

10. Nuestras pruebas aún fallan ya que siempre actualizamos TODO con los campos de solicitud, incluso si están vacíos. Solucione este problema actualizando la implementación para verificar si hay valores vacíos
    

11. La nueva prueba UpdateWithPatch pasa, pero nuestras pruebas anteriores fallan. Dado que cambiamos Completado a *bool, los TODO creados con un valor vacío se mostrarán como nulo
    

12. Implementar renderizado para TODO para que podamos tratar nil como falso
    

La implementación de la función PATCH con desarrollo basado en pruebas dio como resultado un conjunto sólido de pruebas y una función bien implementada. Dado que comenzamos definiendo la entrada y salida esperadas de una solicitud PATCH en las pruebas, fue fácil ver los problemas causados ​​por no verificar valores vacíos en la solicitud. Además, nuestras pruebas preexistentes pudieron proteger contra cambios importantes al cambiar el tipo de Completado a *bool.

Conclusión

El desarrollo basado en pruebas es un enfoque eficaz para crear código correcto y completamente probado. Al comenzar con las pruebas en mente, podemos asegurarnos de que cada fragmento de código esté diseñado para ser comprobable en lugar de dejar que las pruebas sean una ocurrencia tardía.

Si tiene dudas sobre adoptar TDD, aquí tiene algunas ideas para comenzar:

• Pruébelo en escenarios simples donde la entrada/salida de una función sea clara y la implementación no sea demasiado complicada. Puede escribir una prueba de tabla sólida para la variedad de entradas/salidas que podrían encontrarse. Tener una visión clara de los diferentes escenarios puede simplificar la implementación
• Si estás solucionando un nuevo error, ya has identificado una brecha en tus pruebas. Comience escribiendo una prueba que hubiera identificado este error en primer lugar. Luego, haz que esta prueba pase sin romper ninguna prueba existente.
• Al igual que en el ejemplo de babyapi, puedes usar TDD para pruebas de API de alto nivel. Una vez que tenga una definición de la solicitud/respuesta esperada, puede reanudar su flujo de desarrollo habitual para partes de la implementación más detalladas

Incluso si TDD no se adapta bien a la forma en que escribes código, sigue siendo una herramienta poderosa que debes tener a tu alcance. Te animo a que al menos dediques algo de tiempo a probarlo y ver cómo afecta tu proceso de desarrollo.