Ventajas y desventajas del desarrollo dirigido por pruebas (TDD)

Desarrollo dirigido por pruebas (TDD):
el desarrollo dirigido por pruebas (TDD) también se denomina diseño dirigido por pruebas. TDD puede ser un método de desarrollo de software durante el cual el archivo de texto ASCII se prueba una y otra vez ( prueba unitaria ).

El desarrollo basado en pruebas puede ser un enfoque equilibrado para la programación perfectamente combinado con tres actividades estrechamente entrelazadas: codificación, prueba (escribir pruebas unitarias) y diseño (refactorización) como primer objetivo de corregir la especificación en lugar de validar primero. En otras palabras, TDD puede ser un enfoque inteligente para conocer y optimizar las necesidades antes de escribir el código funcional en la línea de los principios ágiles .

Ventajas de TDD:

• Solo escribe el código que se necesita:
  siguiendo los principios, debe evitar escribir código de producción cuando pasen todas las pruebas. Si su proyecto necesita otra función, le gustaría una prueba para impulsar la implementación de la función. El código que escribe es el código más simple posible. Por lo tanto, todo el código que termina dentro del producto es realmente necesario para implementar las funciones.
• Diseño más modular:
  en TDD, considera una microfunción a la vez. Y a medida que escribe la prueba primero, el código automáticamente se vuelve fácil de verificar. El código que es fácil de verificar presenta una interfaz clara. Esto conduce a un diseño modular para su aplicación.
• Más fácil de mantener:
  debido a que las diferentes partes de su aplicación están desacopladas entre sí y tienen interfaces claras, el código se vuelve más fácil de cuidar, intercambiará la implementación de una microfunción con una implementación mucho mejor sin afectar a otro módulo. incluso conservará las pruebas y reescribirá toda la aplicación. Cuando pasen todas las pruebas, habrá terminado.
• Más fácil de refactorizar:
  cada función se prueba exhaustivamente. no debes tener miedo de hacer cambios drásticos porque si todas las pruebas pasan, todo está bien. Ahora, es extremadamente importante porque tú, como desarrollador, mejoras tus habilidades todos los días. Si abre el proyecto después de seis meses de realizar otra cosa, lo más probable es que tenga muchas ideas sobre cómo mejorar el código. Pero tu memoria sobre todas las partes y la forma en que encajan ya no está fresca. Entonces, hacer cambios es a menudo peligroso. Con un conjunto de pruebas completo, mejorará fácilmente el código sin temor a dañar su aplicación.
• Alta cobertura de prueba:
  hay una prueba para cada función. Esto lleva a una alta cobertura de prueba Desarrolla ganar confianza en su código.
• Las pruebas documentan el código: el código de
  prueba le muestra las formas en que se supone que debe usarse su código. Como tal, documenta su código. El código de prueba es un código de muestra que muestra lo que hace el código y la forma en que se debe usar la interfaz.
• Menos depuración:
  ¿con qué frecuencia ha desperdiciado cada día para buscar un error desagradable? ¿Con qué frecuencia ha copiado un mensaje de error de Xcode y lo ha buscado en la web?

Desventajas de TDD:

• Sin solución mágica:
  las pruebas ayudan a buscar errores, pero no pueden encontrar errores que usted simplemente introduce dentro del código de prueba y en el código de implementación. Si no has entendido el asunto que te gustaría desentrañar, es muy probable que escribir pruebas no ayude.
• proceso lento:
  si comienza con TDD, tendrá la sensación de que simplemente necesita una mayor duración de su tiempo para implementaciones sencillas. le gustaría creer en las interfaces, escribir el código de prueba y ejecutar las pruebas antes de que finalmente comience a escribir el código.
• Todos los miembros de un equipo deben hacerlo:
  como TDD influye en la planificación del código, se recomienda que todos los miembros de un equipo usen TDD o que nadie lo use. además, hasta el momento, a veces es difícil justificar TDD a la gerencia porque a menudo tienen la sensación de que la implementación de las últimas funciones lleva más tiempo si los desarrolladores escriben código que no se encontrará dentro del producto la mitad del tiempo. Ayuda si todo el equipo está de acuerdo en la importancia de las pruebas unitarias.
• Las pruebas deben mantenerse cuando cambian los requisitos:
  probablemente, el argumento más fuerte contra TDD es que las pruebas deben mantenerse porque el código tiene que hacerlo. Siempre que cambien los requisitos, le gustaría variar el código y las pruebas. Pero estás trabajando con TDD. esto sugiere que simplemente tiene que cambiar las pruebas primero y luego hacer que pasen las pruebas. Entonces, en realidad, esta desventaja es que es lo mismo que antes al escribir código que aparentemente lleva mucho tiempo. Y lleva mucho tiempo.