Al leer las descripciones, entiendo que en las pruebas de TDD se realizan antes de escribir la función y en la Prueba de unidad, se hace después.
¿Es esta la principal diferencia, o los dos términos ni siquiera pueden compararse como tales? Quizás, Unit Testing es una parte integrada de TDD.
Unit Testing se refiere a qué estás probando, TDD a cuando estás probando.
Los dos son ortogonales.
Prueba de unidad significa, bueno, probar unidades de comportamiento individuales. Una unidad individual de comportamiento es la unidad más pequeña posible de comportamiento que puede probarse 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 escribe su código.
TDD significa (de nuevo, algo obvio) dejar que tus pruebas impulsen tu desarrollo (y tu diseño). Puede hacerlo con pruebas unitarias, pruebas funcionales y pruebas de aceptación. Usualmente, usas los tres.
La parte más importante de TDD es la D central. Dejas que las pruebas te conduzcan . Las pruebas le dicen qué hacer, qué hacer a continuación, cuando haya terminado. Te dicen cuál será la API, cuál será 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 requisito previo para poder permitir que las pruebas guíen el desarrollo).
Puede realizar pruebas unitarias sin realizar un desarrollo guiado por pruebas. Sin embargo, no puede realizar un desarrollo basado en pruebas sin utilizar pruebas unitarias.
Cuando realiza la prueba tradicional de unidad , escribe la prueba después de que escribió su código.
El enfoque dedesarrollo guiado por pruebas es escribir una prueba de unidad antes de escribir 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 mal.
TDD está escribiendo una prueba que fallará, luego escribirá la cantidad mínima de código necesaria para que se ejecute, luego refactorizando el código para que quede limpio. Esto se hace en ciclos, falla - > pase - > refactor, agregando una nueva prueba para cada requisito conocido para el código. Más recientemente, TDD se ha vuelto aún más específicamente sobre la escritura de pruebas unitarias en ese ciclo, para distinguirlo de ATDD (un subconjunto de BDD) que está escribiendo pruebas de aceptación en un ciclo similar.
La prueba de unidad consiste 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 de unidad, como xUnit o Rspec, para ejecutar pruebas, está escribiendo pruebas de unidad. Esto no necesariamente es cierto. Esas herramientas se pueden usar para ejecutar dichas pruebas utilizando el marco de trabajo de Selenium; en ese caso, usted 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 parte de la lógica, aisladas de todo lo demás en aras de la velocidad (para que puedas 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. Unidades de prueba es un término que se usa para describir un tipo de prueba de ámbito limitado que no sea la prueba del sistema, la prueba de integración y la prueba de aceptación.
TDD es un enfoque filosófico para escribir código: escriba las pruebas primero. Las pruebas que escribes son pruebas unitarias.
La forma en que separo los dos es considerar que TDD es menos sobre las pruebas y más sobre el diseño del 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 que se diseñó mediante pruebas.
Todas las respuestas excelentes. 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 que la 'unidad' es el paso incremental más pequeño hacia la funcionalidad deseada ...)
Lea otras preguntas en las etiquetas unit-testing tdd difference