Introducción: ¿por qué escribimos errores y luego los arreglamos heroicamente?
\n\n¿Alguna vez has escrito código que funcionaba "más o menos bien", y luego, tres días después, encontraste un error que lo rompía todo? Si es así, bienvenido al club. Si no, o eres un dios de C++ o simplemente aún no has lanzado a producción.
\n\nEl desarrollo guiado por pruebas (TDD) no es una dieta de moda para programadores. Es una disciplina que pone patas arriba el proceso de escritura de código. En lugar de escribir primero la lógica y luego pensar apresuradamente cómo probarla, hacemos lo contrario: primero la prueba, luego el código. ¿Suena una locura? Quizás. Pero así es como nace el código del que no te avergüenzas mostrar a tus colegas y que no se rompe el viernes por la noche.
\n\nEn este artículo, analizaremos TDD en C++ con ejemplos reales: escribiremos una biblioteca simple para trabajar con números de Fibonacci, utilizando el ciclo Red-Green-Refactor. Verás cómo TDD ayuda no solo a evitar errores, sino también a diseñar interfaces.
\n\n¿Qué es TDD y por qué C++ sin él es como sin frenos?
\n\nTDD (Test-Driven Development) es una metodología de desarrollo en la que primero se escribe una prueba que deliberadamente falla (Red), luego se escribe el código mínimo que hace que la prueba pase (Green), y finalmente se realiza una refactorización (Refactor) para mejorar la estructura sin cambiar el comportamiento.
\n\n¿Por qué es importante esto especialmente para C++? Porque C++ es un lenguaje donde es fácil dispararse en el pie: comportamiento indefinido, fugas de memoria, conversiones de tipo incorrectas. TDD crea automáticamente una red de seguridad que atrapa errores en las etapas de compilación y ejecución.
\n\nEl ciclo Red-Green-Refactor: cómo funciona
\n\n- \n
- Red: escribimos una prueba que debe fallar. Es nuestro "requisito" para el código. \n
- Green: escribimos el código mínimo para que la prueba pase. ¡Nada de sobreingeniería! \n
- Refactor: mejoramos el código (eliminamos duplicación, simplificamos la lógica) — las pruebas siguen en verde. \n
¿Suena simple? Sí. Pero en la práctica requiere disciplina. Vamos a intentarlo.
\n\nHerramientas para TDD en C++: Google Test vs Catch2
\n\nAntes de escribir código, elijamos un framework de pruebas. Dos candidatos principales:
\n\n- \n
- Google Test — potente, popular, con montones de macros. Ideal para proyectos grandes. \n
- Catch2 — ligero, moderno, con sintaxis cómoda. Perfecto para ejemplos educativos y microservicios. \n
En este artículo usaremos Catch2 (v3), porque es minimalista y no requiere configuraciones adicionales. Pero si prefieres Google Test, los principios de TDD son los mismos.
\n\nPráctica: escribimos TDD para números de Fibonacci
\n\nImaginemos que necesitamos escribir una función fibonacci(int n) que devuelva el n-ésimo número de Fibonacci (0-ésimo = 0, 1-ésimo = 1, 2-ésimo = 1, 3-ésimo = 2, etc.).
Paso 1: Red — escribimos una prueba que no pasa
\n\nCreemos un archivo test_fib.cpp:
#define CATCH_CONFIG_MAIN\n#include <catch2/catch_test_macros.hpp>\n\n// Mientras la función no esté declarada, es normal\nint fibonacci(int n);\n\nTEST_CASE("Números de Fibonacci", "[fib]") {\n REQUIRE(fibonacci(0) == 0);\n REQUIRE(fibonacci(1) == 1);\n REQUIRE(fibonacci(2) == 1);\n REQUIRE(fibonacci(10) == 55);\n}\n\nIntentamos compilar — obtenemos un error de enlace. La prueba está en RED. ¡Excelente!
\n\nPaso 2: Green — escribimos el código mínimo para que la prueba pase
\n\nCreemos un archivo fib.cpp:
int fibonacci(int n) {\n if (n <= 1) return n;\n return fibonacci(n - 1) + fibonacci(n - 2);\n}\n\nCompilamos y ejecutamos las pruebas. ¿Pasan? Sí, pero no es eficiente. Sin embargo, nuestro objetivo es Green, no la perfección. Por ahora lo dejamos así.
\n\n