Cuándo simular el acceso a la base de datos

Question

Lo que he hecho muchas veces al probar las llamadas a bases de datos es configurar una base de datos, abrir una transacción y deshacerla al final. Incluso he usado un sqlite db en memoria que creo y destruyo en cada prueba. Y esto funciona y es relativamente rápido.

Mi pregunta es: ¿Debo burlarse de las llamadas bases de datos, debería usar la técnica anterior o debería utilizar tanto - una para prueba de unidad, uno para las pruebas de integración (que, al menos para mí, parece doble trabajo) .

Answer 1

el problema es que si utiliza su técnica de configuración de una base de datos, apertura de transacciones y retroceso, sus pruebas unitarias dependerán del servicio de base de datos, conexiones, transacciones, red y demás. Si se burla de esto, no hay dependencia de otras piezas de código en su aplicación y no hay factores externos que influyan en los resultados de la prueba de la unidad.

El objetivo de una prueba unitaria es probar la pieza más pequeña de código comprobable sin involucrar otra lógica de aplicación. Esto no se puede lograr al usar su técnica IMO.

Hacer que su código sea comprobable mediante la abstracción de su capa de datos, es una buena práctica. Hará que su código sea más robusto y más fácil de mantener. Si implementa un patrón de repositorio, burlarse de sus llamadas a la base de datos es bastante fácil.

También las pruebas unitarias y las pruebas de integración satisfacen diferentes necesidades. Las pruebas unitarias deben probar que una pieza de código está trabajando técnicamente y atrapar casos de esquina. Las pruebas de integración verifican las interfaces entre los componentes frente a un diseño de software. Las pruebas unitarias por sí solas no pueden verificar la funcionalidad de una pieza de software.

HTH

Answer 2

Todo lo que tengo que añadir a @ respuesta de Stéphane es: depende de cómo encajan las pruebas unitarias en sus propias prácticas de desarrollo personal. Si tiene pruebas de integración de extremo a extremo que involucran una base de datos real que crea y ordena según sea necesario, siempre que haya cubierto todas las rutas diferentes a través de su código y las diversas eventualidades que podrían ocurrir cuando los usuarios piratean datos de publicación , etc. - está cubierto desde el punto de vista de sus pruebas y le dice si su sistema está funcionando, lo que probablemente sea el motivo principal de las pruebas.

Supongo que tener cada una de tus pruebas en cada capa de tu sistema hace que el desarrollo basado en pruebas sea muy difícil. Necesitar cada capa en su lugar y trabajar para que pase una prueba prácticamente excluye pasar unos minutos escribiendo una prueba, unos minutos haciéndola pasar y repetirla. Esto significa que sus pruebas no pueden ser guide you en términos de cómo los componentes individuales se comportan e interactúan; sus pruebas no lo forzarán a hacer cosas débilmente acopladas, por ejemplo. Además, supongamos que agrega una nueva función y algo se rompe en otro lugar; las pruebas granulares que se ejecutan en contra de los componentes en forma aislada hacen que sea mucho más fácil rastrear lo que salió mal.

Por estas razones, yo diría que vale la pena el "doble trabajo" de crear y mantener pruebas de integración y de unidad, con su DAL burlado o tropezado en este último.