se ejecutan de la misma manera cada vez. Además, una vez que se configura una prueba automatizada por lo general, será más rápido volver a ejecutar esa prueba automatizada que repetir manualmente una serie de pruebas. Sin embargo, no todas las características de un sistema se pueden probar fácilmente a través de una herramienta de prueba automatizada y, en algunos casos, el entorno físico puede hacer que pruebas difíciles de automatizar. Por lo general, la mayoría de las pruebas unitarias están automatizadas y la mayoría de las pruebas de aceptación son manuales. También tendrá que decidir qué formas de prueba deben llevarse a cabo. La mayoría del software los proyectos deben tener pruebas unitarias, pruebas de integración, pruebas de sistema y aceptación la prueba como requisito necesario. No todos los proyectos implementarán desempeño o prueba de estabilidad, pero debe tener cuidado de no omitir ninguna etapa de prueba y asegúrese de que no es aplicable. 14.6 Desarrollo basado en pruebas Test Driven Development (o TDD) es una técnica de desarrollo mediante la cual el desarrollo Los operadores escriben casos de prueba antes de escribir cualquier código de implementación. Las pruebas así impulsar o dictar el código que se desarrolla. La implementación solo proporciona como tanta funcionalidad como se requiere para pasar la prueba y, por lo tanto, las pruebas actúan como una especificación ficación de lo que hace el código (y algunos argumentan que las pruebas son, por lo tanto, parte de ese especificación y proporcionar documentación de lo que el sistema es capaz de hacer). TDD tiene el beneficio de que como las pruebas deben escribirse primero, siempre hay un conjunto de pruebas disponibles para realizar pruebas unitarias, de integración, de regresión, etc. Esto es bueno como los desarrolladores pueden encontrar que escribir pruebas y mantenerlas es aburrido y de menos interés que el código real en sí mismo y, por lo tanto, poner menos énfasis en el régimen de prueba de lo que podría ser deseable. TDD alienta, y de hecho requiere, que los desarrolladores mantener un conjunto exhaustivo de pruebas repetibles y que esas pruebas se desarrollen para la misma calidad y estándares que el cuerpo principal del código. Hay tres reglas de TDD según lo definido por Robert Martin, estas son:

1. No se le permite escribir ningún código de producción a menos que sea para hacer una falla pase de prueba unitaria
2. No se le permite escribir más de una prueba unitaria de lo que es suficiente para fallar; y fallas de compilación son fallas
3. No está permitido escribir más código de producción del suficiente para aprobar la única prueba unitaria que falla. Esto conduce al ciclo TDD descrito en la siguiente sección. 14.5 Automatización de pruebas 171