Al leer las descripciones, entiendo que en las pruebas TDD se realizan antes de escribir la función y en Pruebas unitarias, se realiza después.
¿Es esta la principal diferencia, o los dos términos ni siquiera se pueden comparar como tales? Quizás, Unit Testing es una parte integrada de TDD.
Respuestas:
Las pruebas unitarias se refieren a lo que está probando, TDD a cuando está probando.
Los dos son ortogonales.
Prueba de unidad significa, bueno, probar unidades individuales de comportamiento. Una unidad de comportamiento individual es la unidad de comportamiento más pequeña posible que se puede probar individualmente de forma aislada. (Sé que esas dos definiciones son circulares, pero parecen funcionar bastante bien en la práctica).
Puede escribir pruebas unitarias antes de escribir su código, después de escribir su código o mientras lo escribe.
TDD significa (nuevamente, algo obvio) dejar que sus pruebas impulsen su desarrollo (y su diseño). Puede hacerlo con pruebas unitarias, pruebas funcionales y pruebas de aceptación. Por lo general, usas los tres.
La parte más importante de TDD es la D central . Dejas que las pruebas te lleven . Las pruebas le dicen qué hacer, qué hacer a continuación, cuando haya terminado. Te dicen cuál será la API, cuál es el diseño. (Esto es importante: TDD no se trata de escribir pruebas primero. Hay muchos proyectos que escriben pruebas primero pero no practican TDD. Escribir pruebas primero es simplemente un prerrequisito para poder dejar que las pruebas dirijan el desarrollo).
Puede realizar pruebas unitarias sin realizar un desarrollo dirigido por pruebas. Sin embargo, no puede hacer un desarrollo impulsado por pruebas sin usar pruebas unitarias.
Cuando haces pruebas unitarias tradicionales , escribes una prueba después de escribir tu código.
El enfoque de desarrollo impulsado por la prueba es escribir una prueba unitaria antes de escribir el código.
Las ventajas más interesantes de TDD (IMHO) en comparación con las pruebas unitarias simples:
TDD y Unit Testing son dos términos muy específicos que a menudo se usan incorrectamente.
TDD está escribiendo una prueba que fallará, luego escribe la cantidad mínima de código requerida para que se ejecute, luego refactoriza el código para que quede limpio. Esto se hace en ciclos, falla -> pasa -> refactoriza, agregando una nueva prueba para cada requisito conocido para el código. Más recientemente, TDD se ha convertido aún más específicamente en escribir pruebas unitarias en ese ciclo, para distinguirlo de ATDD (un subconjunto de BDD) que está escribiendo pruebas de aceptación en un ciclo similar.
Las pruebas unitarias consisten en probar un código en unidades pequeñas y aisladas. La confusión común aquí es pensar que si está utilizando una herramienta de prueba unitaria, como xUnit o Rspec, para ejecutar pruebas, está escribiendo pruebas unitarias. Esto no necesariamente es cierto. Esas herramientas se pueden usar para ejecutar dichas pruebas utilizando el marco Selenium, en ese caso, está escribiendo pruebas de aceptación utilizando un corredor de pruebas unitarias. Las pruebas unitarias son pruebas muy específicas que se centran en una pequeña pieza de lógica, aislada de todo lo demás por razones de velocidad (para que pueda ejecutarlas con frecuencia y obtener comentarios rápidos sobre nuevos errores).
TDD es el enfoque de escribir los casos de prueba antes del desarrollo como usted dijo y luego el desarrollador escribe el código para pasar los casos de prueba. Prueba de unidad es un término utilizado para describir un tipo de prueba de alcance limitado que no sea la prueba del sistema, la prueba de integración y la prueba de aceptación.
La forma en que separo los dos es considerar que TDD se trata menos de pruebas y más de diseñar el código. Las pruebas unitarias se utilizan para establecer las expectativas para el código final. Cuando se escribe el código final y pasa las pruebas (especificaciones), tiene un código diseñado con pruebas.
Todas excelentes respuestas. Solo agregaría que las pruebas unitarias tienden a considerar la 'unidad' como un componente pequeño, mientras que TDD se amplía para incluir pruebas de integración y aceptación.
(Algunas variantes de TDD consideran la 'unidad' como el paso incremental más pequeño hacia la funcionalidad deseada ...)