AnuncioEl desarrollo basado en pruebas (también programación basada en pruebas; el primer desarrollo de prueba o desarrollo basado en pruebas (TDD) es un método que se utiliza a menudo en el desarrollo ágil de programas informáticos. En el desarrollo basado en pruebas, el programador crea consistentemente pruebas de software antes Según el enfoque clásico, por ejemplo según el modelo en cascada o en V, las pruebas se desarrollan en paralelo e independientemente del sistema que se va a probar, o incluso después de él, lo que a menudo lleva a que que el código es difícil de probar, por lo que el esfuerzo requerido para las pruebas es alto y no logran la cobertura de prueba deseada o requerida. Las posibles razones para esto incluyen: Falta o falta de capacidad de prueba del sistema (monolítico, uso de terceros). (componentes del partido, …). Prohibición de invertir en partes no funcionales del programa por parte de la dirección de la empresa (“El trabajo que no se ve más adelante en el programa se desperdicia”). Creación de pruebas bajo presión de tiempo o simplemente para lograr la cobertura de prueba deseada. Negligencia y falta de disciplina por parte de los programadores en la creación de pruebas. Centrarse en la prueba de caja blanca en el sistema a probar y sus peculiaridades y las pruebas resultantes «alrededor de errores». El desarrollo impulsado por pruebas intenta contrarrestar estas desventajas de las pruebas de caja blanca y también conseguir un diseño de software que se adapte mejor a la tarea del software y sea más fácil de mantener. Cuando se utiliza el desarrollo impulsado por pruebas, se puede corregir un promedio del 45 por ciento de todos los errores. detectado o evitado. En comparación, sólo el 30 por ciento de los errores se detectan en promedio cuando se utilizan pruebas unitarias solas. Críticas al desarrollo basado en pruebas La principal objeción al desarrollo basado en pruebas es el supuestamente alto esfuerzo. Sin embargo, la idea descrita aprovecha el hecho de que el esfuerzo mental que se invierte en la descripción constructiva, es decir, el programa, durante la programación, y constituye la mayor parte del tiempo de programación (en relación con el esfuerzo de mecanografía, por ejemplo), Incluye una lista de puntos individuales y casos a cumplir. Con un poco más de esfuerzo, el caso a tratar se puede describir exactamente en este momento antes de programar y escribir algunas líneas de prueba de antemano puede incluso conducir a una mejor estructuración mental y una mayor calidad del código. En segundo lugar, el desarrollo basado en pruebas conduce a una cierta disciplina sobre qué funciones se implementan en qué orden, porque primero hay que pensar en un caso de prueba y, por lo tanto, potencialmente a una mayor consideración de los beneficios para el cliente; consulte también YAGNI.Pruebas unitarias o automatizadas. Las pruebas en general se describen a menudo como la red de seguridad de un programa para los cambios necesarios; sin un alto nivel de cobertura de pruebas, un sistema de software es generalmente más susceptible a errores y problemas en el desarrollo y mantenimiento posteriores. Incluso en la primera creación, con un poco de práctica para cumplir una determinada funcionalidad, el esfuerzo con TDD puede ser menor que el esfuerzo de una solución supuestamente rápida y sin pruebas automatizadas. Según la opinión consensuada, esto es tanto más cierto cuanto más duradero sea el sistema y, por tanto, sujeto a cambios repetidos. El esfuerzo necesario para escribir pruebas automatizadas posteriormente es mucho mayor, porque los requisitos individuales y las líneas del programa deben analizarse mentalmente nuevamente, y una cobertura de prueba comparable a la de TDD es difícilmente realista sólo por razones de esfuerzo y coste. El desarrollo impulsado también puede usarse incorrectamente y luego fallar. Para los programadores que no tienen experiencia en esto, a veces parece difícil o incluso imposible. Te preguntas cómo probar algo que ni siquiera existe todavía. La consecuencia puede ser que se descuiden los principios de este método, lo que puede resultar en dificultades en el proceso de desarrollo o incluso en su colapso, especialmente en métodos ágiles como la programación extrema. Sin suficientes pruebas unitarias, no se logrará una cobertura de prueba suficiente para la refactorización y la calidad deseada. Esto se puede contrarrestar con programación y entrenamiento en pares. Un argumento importante de los oponentes del desarrollo basado en pruebas es que las pruebas unitarias en particular aumentan innecesariamente el esfuerzo involucrado en los cambios en la funcionalidad existente, porque un cambio en el código de producción causa un número desproporcionado de unidades. pruebas para fallar. Sin embargo, la razón de esto suele ser que la unidad probada no ha sido suficientemente separada, es decir, las pruebas no son atómicas. Para evitar este problema, es necesario que los programadores estén capacitados sobre cómo dividir los requisitos en unidades funcionales atómicas y practicar. haciéndolo.