Diferencia entre pruebas unitarias y desarrollo guiado por pruebas

64

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.

unit-testing tdd difference Shamim Hafiz
fuente

Respuestas:

104

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).

Jörg W Mittag
fuente
1
Gran respuesta. agregaría ... TDD es cuando dejas que las pruebas te empujen y características para tirar de tus esfuerzos de desarrollo ...
Martin
Sin embargo, no son ortogonales. No puede tener TDD sin pruebas unitarias.
JacquesB
1
@JacquesB, ¿por qué? Nuestras pruebas no son lo que llamarías pruebas unitarias por definición, dependen demasiado de la infraestructura y otros componentes, pero todavía tenemos suficiente capacidad de observación que nosotros, bueno, al menos algunos de nosotros, estamos haciendo TDD.
Programador del
3
@ AndrewWillems: TDD significa que las pruebas impulsan el desarrollo . Usted no decide cómo se ve el diseño, las pruebas le dicen. No decides en qué trabajar a continuación, te dicen las pruebas. No decides cuándo has terminado, te dicen las pruebas. Es perfectamente posible escribir pruebas primero, y luego ignorar todo lo que le están diciendo. Por ejemplo, podría escribir pruebas primero, pero luego seguir escribiendo código incluso después de que todas las pruebas sean verdes. En otras palabras: primero escribes las pruebas, pero las tratas solo como pruebas y no dejas que dirijan el desarrollo.
Jörg W Mittag
1
@ JörgWMittag Puede que tenga razón de una manera purista de verlo, pero también sabe que TDD no es blanco y negro. Cualquier uso sensato de TDD no permitiría que las pruebas impulsen el desarrollo por completo, y las pruebas definitivamente no siempre deciden cómo se ve el diseño (tal vez las pruebas unitarias pueden hacer esto en parte, pero no las pruebas en un nivel de abstracción más alto). ¿Qué pasa con la refactorización? Lo cual es un aspecto muy importante de TDD. Además, en el mundo real no existe "ignorar todo lo que la prueba le dice". Por definición, si escribe pruebas primero, usa 'alguna forma de TDD'.
NickL
21

Las pruebas unitarias son un componente del desarrollo dirigido por pruebas

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:

  • El código se prueba completamente por adelantado. Es una prueba indolora.
  • Te obliga a diseñar tus clases correctamente.
  • También te obliga a mantenerlo simple estúpido .
  • ¡El ciclo de Red-Green-Refactor es el asesino absoluto de la dilación!

fuente
¿Te has perdido la "unidad" a propósito en la declaración: "Sin embargo, no puedes hacer un desarrollo basado en pruebas sin usar las pruebas". ?
ratkok
@ratkok: no, eso no fue a propósito. Déjame arreglar eso.
Me gusta esta definición lo mejor. Es mejor juntarlo en palabras que otras respuestas.
Tek
2
Podría decirse que puede hacer TDD usando pruebas de módulo o pruebas de sistema en lugar de pruebas de unidad verdaderas. No lo recomendaría, ya que pierde gran parte del beneficio si las pruebas tardan demasiado en ejecutarse, pero no es imposible.
Toby Speight
13

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).

pdr
fuente
1
Las pruebas JUnit para JUnit en sí son un buen ejemplo: una parte significativa de ellas son pruebas funcionales y pruebas de aceptación, no pruebas unitarias, aunque estén escritas en JUnit. Además, el creador de JUnit también es el creador de TDD, y JUnit se desarrolló utilizando TDD utilizando una cantidad significativa de pruebas funcionales y pruebas de aceptación. La prueba de aceptación es una parte integral de TDD.
Jörg W Mittag
6

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.

M.Sameer
fuente
3

TDD es un enfoque filosófico para escribir código: primero escriba las pruebas. Las pruebas que escribe son pruebas unitarias.

Tangurena
fuente
1

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.

Grant Palin
fuente
1

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 ...)

Steven A. Lowe
fuente
deberían, pero en mi experiencia en realidad no lo hacen. Las empresas / grupos dicen que hacen TDD, cuando todo lo que hacen es forzar a los programadores a probar primero con las pruebas de jUnit, luego usan el hecho de que todo ya se probó durante el desarrollo para eliminar (o reducir en gran medida) el control de calidad y las pruebas de integración.
Juent
1
@jwenting no culpe a la metodología por las deficiencias de aquellos que dicen practicarla. cualquier herramienta puede ser mal utilizada
Steven A. Lowe
1
No, pero debes darte cuenta de que hay una gran diferencia entre lo que TDD es en teoría y lo que es en realidad. Y como la mayoría de las personas (OP incluida) probablemente solo vean la realidad, se les debe señalar la diferencia.
Jwent
Teniendo en cuenta que TDD se trata de diseño, ¿por qué incluiría pruebas de aceptación? ¿Cómo "conduciría" el diseño?
Vitalii Isaenko
Las pruebas de aceptación de @VitaliiIsaenko proporcionan el alcance de más alto nivel para los diseños
Steven A. Lowe