Test-driven Development
Desarrollo guiado por pruebas
El desarrollo guiado por pruebas (TDD) repite tres pasos. Escribe una pequeña prueba que falle. Escribe el mínimo código que pase la prueba. Luego limpia el código sin cambiar su funcionamiento.
Otro ejemplo
Un desarrollador comienza una nueva regla de redondeo de dinero con un ejemplo de prueba que falla. El código más pequeño la hace pasar, luego el código repetido se limpia mientras todas las pruebas permanecen verdes. Las pruebas escritas solo después del código son útiles, pero eso no es el ciclo de "primero la prueba" de TDD.
Partes principales
- 01ejemplo fallido
- 02código mínimo aprobado
- 03refactorización segura
Úsalo cuando
Use este término cuando cada siguiente paso de diseño esté guiado por una prueba fallida y seguido de una limpieza segura.
No lo uses cuando
No llames a un proyecto TDD solo porque tenga muchas pruebas. El código debe seguir el ciclo test-first.
Nombre usado en código
red → green → refactor Antes de lanzarlo
Check the environment and prepared test data (fixture). Define a result you can observe, failure and edge cases, isolation, stable inputs, useful error details, and cleanup. Set a time budget, owner, and flaky-test rule.
Outcome: Complete the task with Desarrollo guiado por pruebas (Test-driven Development). User context: Un desarrollador comienza una nueva regla de redondeo de dinero con un ejemplo de prueba que falla. El código más pequeño la hace pasar, luego el código repetido se limpia mientras todas las pruebas permanecen verdes. Las pruebas escritas solo después del código son útiles, pero eso no es el ciclo de "primero la prueba" de TDD. Validation approach: Desarrollo guiado por pruebas (Test-driven Development). Why it fits: Use este término cuando cada siguiente paso de diseño esté guiado por una prueba fallida y seguido de una limpieza segura. Do not use it when: No llames a un proyecto TDD solo porque tenga muchas pruebas. El código debe seguir el ciclo test-first. Test requirements: Name the system and test environment. Define prepared test data, other inputs, and the result you can observe. Include failure and edge cases, allowed error, isolation, and cleanup. Test operations: Make failures easy to diagnose. Control random or changing inputs. Name an owner. Keep the test fast and simple enough for its release gate. Acceptance criteria: The test fails for the known bug and passes after the fix. It repeats in the target environment, gives useful evidence, and does not expose or change unrelated data. Evidence and limits (evidence boundary): Ningún estándar oficial único controla todo el término. Su significado puede cambiar según equipos, plataformas o marcos. Unknowns to confirm: Release gate, environment, prepared test data, allowed error, time budget, owner, and flaky-test rule.
Revisa esta petición
Review how Desarrollo guiado por pruebas (Test-driven Development) is used now. Definition: El desarrollo guiado por pruebas (TDD) repite tres pasos. Escribe una pequeña prueba que falle. Escribe el mínimo código que pase la prueba. Luego limpia el código sin cambiar su funcionamiento. Release checks: Check the environment and prepared test data (fixture). Define a result you can observe, failure and edge cases, isolation, stable inputs, useful error details, and cleanup. Set a time budget, owner, and flaky-test rule. Before changing code, list the evidence, gaps, severity, and the smallest safe fix.