Actualmente estoy aprendiendo acerca de las pruebas unitarias y pruebas de integración y como lo entendía, pruebas de unidad se utilizan para probar la lógica de un análisis de clase y de integración específicos se utilizan para comprobar la cooperación de varias clases y bibliotecas.
Pero es que sólo se utiliza para múltiples clases de prueba y si trabajan juntos como se esperaba, o es también válido para las bases de datos de acceso en una prueba de integración? Si es así, ¿y si la conexión no puede establecerse debido a un error del servidor caras, no las pruebas falla, aunque el propio código funcionaría como se esperaba? ¿Cómo sé lo que es válido para su uso en este tipo de pruebas?
La segunda cosa que no entiendo es cómo se configuran. Las pruebas unitarias me parecen tener una forma bastante común, como:
public class classTest {
@BeforeEach
public void setUp(){
}
@Test
public void testCase(){
}
}
Pero, ¿cómo se escriben las pruebas de integración? ¿Es comúnmente realiza de la misma manera, simplemente incluyendo más clases y factores externos o hay otra manera que se utiliza para eso?
[...] es también válido para las bases de datos de acceso en una prueba de integración? [...] ¿Cómo sé lo que es válido para su uso en este tipo de pruebas?
La distinción entre la unidad de pruebas y pruebas de integración no es si o no más de un componente está involucrado: Incluso en la unidad de pruebas de que puede arreglárselas sin burlarse de todas sus dependencias si estas dependencias no le impiden alcanzar sus metas de la unidad de pruebas de (ver https://stackoverflow.com/a/55583329/5747415 ).
Lo que distingue a pruebas unitarias y pruebas de integración es el objetivo de la prueba. Como usted escribió, en la unidad de pruebas de su atención se centra en la búsqueda de errores en la lógica de una función, método o clase. En pruebas de integración El objetivo es entonces, obviamente, para detectar los errores que no se pudo encontrar durante la unidad de pruebas, pero se pueden encontrar en el sistema integrado (sub-). Manteniendo siempre los objetivos de la prueba en mente ayuda a crear mejores pruebas y para evitar redundancias innecesarias entre las pruebas de integración y unidad de pruebas.
Un sabor de las pruebas de integración es la prueba de interacción: En este caso, el objetivo es encontrar errores en la interacción entre dos o más componentes. (Componentes adicionales puede ser burlado, o no - de nuevo esto depende de si los componentes adicionales que impiden alcanzar los objetivos de prueba.) Las preguntas típicas en las interacciones de dos componentes Ay Bpodría ser, por ejemplo, si Bes una biblioteca: es el componente Allamando al función derecha de componente B, es el componente Ben un estado adecuado para ser visitada por Avía esa función ( Bpodría no ser inicializado todavía), se Apasa a los argumentos en el orden correcto, no los argumentos contienen los valores en la forma esperada, haceB devolver los resultados en la forma esperada y en el formato esperado?
Otro sabor de las pruebas de integración es la prueba de subsistema, en el que no se centra en las interacciones entre los componentes, pero vistazo a los límites del subsistema formado por los componentes integrados. Y, de nuevo, el objetivo es encontrar errores que no pudieron ser encontrados por las pruebas anteriores (es decir, unidad de pruebas y pruebas de interacción). Por ejemplo, son los componentes integrados en las versiones correctas, pueden ejercerse los casos de uso deseadas en el Integrated subsistema etc.
Mientras unidad de pruebas forman la parte inferior de la pirámide de la prueba , las pruebas de integración es un concepto que se aplica en diferentes niveles de integración e incluso puede centrarse en las interfaces ortogonal a la estrategia de integración de software (por ejemplo, al realizar calibraciones de la interacción de un conductor y su correspondiente hardware dispositivo).
La segunda cosa que no entiendo es cómo se configuran. [...] cómo se escriben las pruebas de integración?
Existe una variación extrema aquí. Para muchas pruebas de integración sólo se puede utilizar el mismo marco de pruebas que se utiliza para la unidad de pruebas: No hay nada específico unidad de prueba en estos marcos. Usted, sin duda, en la prueba de los casos tienen que asegurarse de que la configuración en realidad combina los componentes de interés en sus versiones apropiadas. Y, si es o no dependencias adicionales sólo son utilizadas o necesidades que puedan decidir burlaban (véase más arriba).
Otro caso típico es llevar a cabo las pruebas de integración en el sistema totalmente integrado, utilizando una configuración de sistema de prueba similar. Esto se hace a menudo por conveniencia, sólo para evitar la molestia de crear diferentes configuraciones especiales para las diferentes pruebas de integración: El sistema totalmente integrado solo tiene a todos juntos. Desde luego, esto también tiene desventajas, ya que a menudo es imposible o al menos poco práctico para realizar todas las pruebas de integración según se desee de esta manera. Y, al hacer pruebas de integración de esta manera los límites entre las pruebas de integración y pruebas del sistema pueden borrarse. Mantenimiento centrado en un medio tal caso, usted realmente tiene que tener una buena comprensión de los diferentes objetivos de prueba.
También existen formas mixtas, pero hay demasiados para describirlos aquí. Sólo un ejemplo, existe la posibilidad de burlarse de algunas bibliotecas compartidas con la ayuda de LD_PRELOAD( ¿Cuál es el truco LD_PRELOAD? ).