Si un proyecto tiene una cobertura de prueba unitaria del 100%, ¿aún se necesitan pruebas de integración?

Question

Si un proyecto tiene una cobertura de prueba unitaria del 100%, ¿aún se necesitan pruebas de integración?

Nunca he trabajado en un proyecto con cobertura de prueba unitaria del 100%, pero me pregunto si su proyecto obtiene esto (o en el 90%). ¿Sabía que aún necesitaba pruebas de integración? (¿Necesitabas menos?)

Lo pregunto porque las pruebas de integración parecen ser malas. A menudo son lentos, frágiles (se rompen fácilmente), opacos (cuando alguien está roto, alguien tiene que sumergirse en todas las capas para descubrir qué está mal) y están causando que nuestro proyecto vaya más lento ... Empiezo a pensar que tengo solo pruebas unitarias (y tal vez un pequeño puñado de pruebas de humo) es el camino a seguir.

En el largo plazo, parece que las pruebas de integración (en mi experiencia) cuestan más de lo que ahorran.

Gracias por su atención.

Answer 1

Definiciones

creo que es importante definir sus términos antes de tener esta discusión.

La unidad de prueba prueba una sola unidad en aislamiento. Para mí, esa es una clase. Una prueba unitaria creará un objeto, invocará un método y verificará un resultado.Responde a la pregunta "¿mi código hace lo que pretendía que hiciera?"

Prueba de integración prueba la combinación de dos componentes en el sistema. Se centra en la relación entre los componentes, no los componentes mismos. Responde a la pregunta "¿estos componentes funcionan juntos como se esperaba?".

Prueba del sistema prueba todo el sistema de software. Responde a la pregunta "¿funciona este software como se esperaba?"

La prueba de aceptación es una forma automatizada para que el cliente responda la pregunta "¿este software es lo que creo que quiero?". Es un tipo de prueba del sistema.

Tenga en cuenta que ninguna de estas pruebas responde preguntas como "¿es útil este software?" o "¿este software es fácil de usar?".

Todas las pruebas automatizadas están limitadas por el axioma "extremo a extremo es más allá de lo que piense" - eventualmente un humano tiene que sentarse frente a una computadora y mirar su interfaz de usuario.

comparaciones

Las pruebas unitarias son más rápidas y más fáciles de escribir, más rápido de ejecutar, y más fácil de diagnosticar. No dependen de elementos "externos" como un sistema de archivos o una base de datos, por lo que son mucho más simples/más rápidos/confiables. La mayoría de las pruebas unitarias continúan funcionando a medida que se refactoriza (y las buenas pruebas unitarias son la única forma de refactorizar de forma segura). Requieren absolutamente que su código sea desacoplado, lo cual es difícil, a menos que primero escriba la prueba. Esta combinación de factores hace que la secuencia Red/Green/Refactor de TDD funcione tan bien.

Las pruebas del sistema son difíciles de escribir, ya que tienen que pasar por tanta configuración para llegar a una situación específica que desea probar. Son frágiles, porque cualquier cambio en el comportamiento del software anterior puede afectar la secuencia que conduce a la situación que desea probar, incluso si ese comportamiento no es relevante para la prueba. Son mucho más lentos que las pruebas unitarias por razones similares. Las fallas pueden ser muy difíciles de diagnosticar, tanto porque puede llevar mucho tiempo llegar al punto de falla como porque el software está involucrado en la falla. En algunos programas, las pruebas del sistema son muy difíciles de automatizar.

Las pruebas de integración se encuentran en el medio: son más fáciles de escribir, ejecutar y diagnosticar que las pruebas del sistema, pero con una cobertura más amplia que las pruebas unitarias.

Recomendación

utilizar una combinación de estrategias de ensayo para equilibrar los costos y los valores de cada uno.

Answer 2

Sí, además hay algunos tipos diferentes de cobertura de código

from wiki:

• cobertura función - se ha ejecutado cada función en el programa?
• Cobertura de extracto - ¿Se ha ejecutado cada línea del código fuente?
• Cobertura de decisión (también conocida como cobertura de sucursal): ¿cada estructura de control (como una declaración if) se ha evaluado como verdadera y falsa?
• Condición de cobertura - ¿Se ha evaluado cada una de las expresiones secundarias booleanas en verdadero y falso (esto no implica necesariamente una cobertura de decisión)?
• Condición modificada/Cobertura de decisión (MC/DC) - ¿Tiene cada condición en una decisión tomada en todos los resultados posibles al menos una vez? ¿Se ha demostrado que cada condición afecta el resultado de la decisión de forma independiente?
• Cobertura de ruta - ¿Se han ejecutado todas las rutas posibles a través de una parte determinada del código?
• Cobertura de entrada/salida - ¿Se han ejecutado todas las posibles llamadas y devoluciones de la función?

Cobertura del camino, por ejemplo, el hecho de que cada método haya sido llamado no significa que no ocurrirán errores si llama a varios métodos en un orden determinado.

Answer 3

Sí.

Incluso si todas las "unidades" hacen lo que se supone que deben hacer, no es garantía de que el sistema completo funcione como se diseñó.

Answer 4

Las pruebas unitarias son diferentes a las pruebas de integración.

Solo para aclarar algo: si tuviera que elegir, enviaría las pruebas unitarias e iría con las pruebas de integración. La experiencia dice que las pruebas unitarias ayudan a garantizar la funcionalidad y también a encontrar errores al principio del ciclo de desarrollo.

Las pruebas de integración se realizan con un producto que se ve cerca de lo que se vería para los usuarios finales. Eso es importante también

Answer 5

Las pruebas unitarias generalmente tratan de probar su clase de forma aislada. Deben diseñarse para garantizar que, dados aportes específicos, su clase muestre comportamientos predecibles y esperados.

Las pruebas de integración generalmente consisten en probar sus clases en combinaciones entre sí y con programas "externos" que usan esas clases. Deben enfocarse en asegurar que cuando el producto en general use sus clases lo haga de la manera correcta.

Answer 6

Sí, porque la funcionalidad de su software depende de cómo interactúa la pieza diferente. Las pruebas unitarias dependen de que usted ingrese las entradas y defina el resultado esperado. Hacer esto no garantiza que funcione con el resto de su sistema.

Sí, las pruebas de integración son difíciles de manejar cuando introduce cambios de código que cambian deliberadamente la salida. Con nuestro software minimizamos esto al enfocarnos en comparar el resultado de salvar de una prueba de integración con un resultado correcto guardado.

Tenemos una herramienta que puede usar cuando estamos seguros de que estamos produciendo los resultados correctos. Va y carga los resultados correctos guardados anteriormente y los modifica para que funcionen con la nueva configuración.

Answer 7

En primer lugar, la cobertura de prueba del 100% de la unidad no es suficiente, ni siquiera a nivel de prueba unitaria: cubre solo el 100% de las instrucciones de su código. ¿Qué hay de las rutas en tu código? ¿Qué pasa con los dominios de entrada o salida?

En segundo lugar, no sabe si la salida de una unidad emisora ​​es compatible con la entrada de su unidad receptora. Este es el propósito de las pruebas de integración.

Finalmente, las pruebas unitarias pueden realizarse en un entorno diferente de la producción. Las pruebas de integración pueden revelar discrepancias.

Answer 8

"opaco (cuando alguien roto tiene que pasar por todas las capas para averiguar qué está mal)" - esta es exactamente la razón por la que se realizan las pruebas de integración; de lo contrario, estos problemas aparecerían en el entorno de producción.

Answer 9

De rutina veo todo tipo de problemas descubiertos por las buenas pruebas de integración, especialmente si puede automatizar algunas de sus pruebas de integración.

Las pruebas de unidad son geniales, pero puede lograr una cobertura de código del 100% sin un 100% de relevancia en las pruebas de su unidad. Realmente estás tratando de probar cosas diferentes, ¿verdad? En las pruebas unitarias, generalmente se buscan casos límite para una función específica, mientras que las pruebas de integración mostrarán problemas a un nivel superior a medida que todas estas funciones interactúen.

Si construye una API en su software, puede usar esto para las pruebas de integración automatizada: en el pasado obtuve mucho rendimiento. No sé si llegaría a decir que pasaría las pruebas unitarias a favor de las pruebas de integración, pero cuando se hacen bien, son una adición realmente poderosa.

Answer 10

This exact question básicamente se acaba de pedir hace un día. Consulte this question para conocer la gran cantidad de errores que puede encontrar, incluso con una cobertura de código del 100%.

Answer 11

Solo puede probar la presencia de un error usando pruebas/cobertura, pero nunca puede probar que el código no tiene errores usando pruebas/cobertura. Este hecho indica los límites de las pruebas/cobertura. Esto es lo mismo en matemáticas, puedes refutar un teorema encontrando un contraejemplo, pero nunca puedes probar un teorema al no encontrar un contraejemplo. Entonces, las pruebas y la cobertura son solo un sustituto de las pruebas de corrección, que son tan difíciles de hacer que casi nunca se usan. Las pruebas y la cobertura pueden mejorar la calidad del código, pero no hay garantía. Sigue siendo una artesanía y no una ciencia.

Answer 12

Parece que no se mencionó aquí, pero nunca se puede tener una cobertura de prueba del 100% de la unidad (si tiene una base de datos involucrada). En el momento en que escribe una prueba unitaria para la conectividad de la base de datos y las operaciones CRUD, acaba de crear una prueba de integración. La razón es porque su prueba ahora tiene una dependencia fuera de las unidades de trabajo individuales. Los proyectos en los que he trabajado y los desarrolladores con los que he hablado siempre han indicado que el 10% restante es la capa DAO o de servicio. La mejor manera de probar eso es con las pruebas de integración y una base de datos simulada (en memoria). He visto intentos de burlar conexiones para probar el DAO, pero realmente no entiendo el punto: su DAO es solo una forma de serializar datos brutos de un formato a otro, y su gerente o delegado decidirá cómo manipularlo

Answer 13

Realmente no he visto una respuesta que cubra estas consideraciones. Ahora, estoy hablando desde una perspectiva holística de sistemas, no desde una perspectiva de desarrollo SW, pero ... La integración es básicamente el proceso de combinar productos de nivel inferior en un producto de nivel superior. Cada nivel tiene su propio conjunto de requisitos para cumplir. Aunque es posible que algunos requisitos sean los mismos, los requisitos generales establecidos serán diferentes para diferentes niveles. Esto significa que los objetivos de la prueba son diferentes en diferentes niveles. Además, el entorno del entorno del producto de nivel superior tiende a ser diferente del producto de nivel inferior (por ejemplo, las pruebas del módulo SW pueden tener lugar en un entorno de escritorio, mientras que un elemento SW cargable completo puede probarse cuando se carga en su HW componente). Además, los desarrolladores de componentes de nivel inferior pueden no tener la misma comprensión de los `requisitos y diseño que los desarrolladores de productos de nivel superior, por lo que las pruebas de integración también validan hasta cierto punto el desarrollo de productos de nivel inferior.