¿Necesito una prueba de unidad si ya tengo una prueba de integración?

41

Si ya tengo una prueba de integración para mi programa, y todos pasaron, tengo la sensación de que funcionará. Entonces, ¿cuáles son las razones para escribir / agregar pruebas unitarias? Como ya tengo que escribir pruebas de integración de todos modos, me gustaría escribir solo pruebas unitarias para partes que no están cubiertas por las pruebas de integración.

Lo que sé, el beneficio de la prueba unitaria sobre la prueba de integración, son

  • Pequeño y, por lo tanto, rápido de ejecutar (pero agregar una nueva unidad para probar algo ya ha sido probado por la prueba de integración significa que mi traje de prueba total se hace más grande y más largo para correr)
  • Localice el error más fácilmente porque solo prueba una cosa (pero puedo comenzar a escribir una prueba unitaria para verificar cada parte individual cuando mi prueba de integración falló)
  • Busque un error que no se pueda detectar en la prueba de integración. p.ej. Enmascaramiento / compensación de errores. (pero si mi integración prueba todas las pasadas, lo que significa que mi programa funcionará incluso si existe algún error oculto. Por lo tanto, encontrar / corregir estos errores no son realmente de alta prioridad a menos que comiencen a romper futuras pruebas de integración o causen problemas de rendimiento)

Y siempre queremos escribir menos código, pero las pruebas de unidad de escritura necesitan mucho más código (principalmente, configurar objetos simulados). La diferencia entre algunas de mis pruebas unitarias y las pruebas de integración es que en las pruebas unitarias, uso un objeto simulado, y en las pruebas de integración, uso un objeto real. Que tienen mucha duplicación y no me gusta el código duplicado, ni siquiera en las pruebas porque esto agrega una sobrecarga para cambiar el comportamiento del código (la herramienta refactor no puede funcionar todo el tiempo).

    
pregunta Bryan Chen 14.07.2013 - 13:55

5 respuestas

28

Ha presentado buenos argumentos a favor y en contra de las pruebas unitarias. Así que debes preguntarte, " ¿Veo valor en los argumentos positivos que superan los costos en los negativos? " Ciertamente:

  • Pequeño y rápido es un aspecto agradable de las pruebas unitarias, aunque no es el más importante.
  • Locating-bug [s] -easier es extremadamente valioso. Muchos estudios de desarrollo de software profesional han demostrado que el costo de un error aumenta considerablemente a medida que envejece y se mueve hacia abajo en la tubería de entrega de software.
  • Encontrar errores enmascarados es valioso. Cuando sabe que un componente en particular tiene todos sus comportamientos verificados, puede usarlo de una manera que no se usó previamente, con confianza. Si la única verificación es mediante pruebas de integración, solo sabe que sus usos actuales se comportan correctamente.
  • La burla es costosa en los casos del mundo real, y mantener las burlas es doblemente así. De hecho, cuando se burlan de objetos o interfaces "interesantes", es posible que incluso necesite pruebas que verifiquen que sus objetos simulados modelan correctamente sus objetos reales.

En mi libro, las ventajas superan a las desventajas.

    
respondido por el Ross Patterson 14.07.2013 - 15:22
8

No veo mucho valor en la reimplementación de un case-test de integración existente como un test de unidad.

Las pruebas de integración a menudo son mucho más fáciles de escribir para aplicaciones heredadas no tdd porque generalmente las funcionalidades a probar están estrechamente relacionadas, por lo que las unidades de prueba aisladas (= prueba de unidad) pueden ser difíciles / costosas / imposibles.

> Then what are the reasons to write/add unit tests?

En mi opinión, el desarrollo guiado por pruebas es más efectivo si escribe las pruebas unitarias antes del código real. De esta manera, el código que cumple con las pruebas se separa claramente con un mínimo de referencias externas que se pueden probar fácilmente.

Si el código ya existe sin las pruebas de unidad, generalmente es mucho trabajo adicional escribir las pruebas de unidad después porque el código no se escribió para una prueba fácil.

Si haces TDD, el código se puede probar fácilmente.

    
respondido por el k3b 14.07.2013 - 16:38
5

Las pruebas de integración solo deben verificar que varios componentes funcionan juntos como se espera. Si la lógica de los componentes individuales es precisa o no, debe verificarse mediante pruebas unitarias.
La mayoría de los métodos tienen varias rutas de ejecución posibles; piense en las variables de entrada if-then-else, con valores inesperados o simplemente erróneos, etc. Por lo general, los desarrolladores tienden a pensar solo en el camino feliz: el camino normal que no sale mal. Pero en lo que respecta a las otras rutas, tiene dos opciones: puede permitir que su usuario final explore esas rutas a través de las acciones que realizan en la interfaz de usuario y espera que no bloqueen su aplicación, o puede escribir pruebas unitarias que afirman el comportamiento de esos otros caminos y tomar medidas cuando sea necesario.

    
respondido por el Stefan Billiet 15.07.2013 - 12:31
4

Algunas de las razones que ha señalado en su pregunta son realmente importantes y por sí mismas podrían justificar el caso en favor de las pruebas unitarias, pero YMMV. Por ejemplo, ¿con qué frecuencia ejecuta su suite de prueba integrada? Mi experiencia con las pruebas integradas es que tarde o temprano se volverán tan lentas que no las ejecutará cada vez que realice un cambio y aumentará el tiempo entre la inserción y la detección de un error.

Además, un gran error que puede estar cometiendo es confiar en que

Find bug that may not be caught in integration test. e.g. masking/offsetting bugs.

no es importante. ¿Estás esperando que tus usuarios encuentren los errores por ti? Confiar en las coberturas obtenidas a partir de pruebas integradas es peligroso, en mi opinión, es muy fácil obtener un alto porcentaje de cobertura, pero en realidad estás probando muy poco.

Supongo que la referencia canónica contra las pruebas integradas son las publicaciones de JBrains:

enlace

en caso de que no los hayas leído ya.

Finalmente, IMO, la retroalimentación que puede obtener de las pruebas de unidad para su diseño es invaluable. Juzgar un diseño por instinto y confiar en pruebas integradas también puede ser un error.

    
respondido por el José Ricardo 14.07.2013 - 23:40
1

Si espera alguna vez tener que modificar o refactorizar su código, es esencial realizar pruebas unitarias. Las pruebas unitarias existen no solo para demostrar errores en el momento en que se escribe el código, sino también para mostrar cuándo aparecen nuevos errores cuando se escribe más código.

Sí, es mucho mejor escribir primero sus pruebas de integración y unidad, pero es muy valioso tenerlas incluso si se escriben más adelante.

    
respondido por el Matthew Flynn 14.07.2013 - 23:53

Lea otras preguntas en las etiquetas