¿Es razonable exigir que las pruebas unitarias nunca se comuniquen con una base de datos/servicio web en vivo?

Question

Mi equipo continúa encontrando más y más valor en las pruebas unitarias que escribimos. Por lo general, no probamos por unidad las capas de acceso a datos de nuestras aplicaciones, ya que no contienen "lógica". En mi experiencia, hemos tenido problemas de rendimiento y errores no reproducibles como resultado de permitir que los desarrolladores escriban pruebas unitarias que hablan con bases de datos en vivo (o servicios web) y como resultado más y más desarrolladores están creando burlas que alimentan datos a estos pruebas unitarias

Este enfoque ha aumentado la velocidad de las pruebas y las pruebas aisladas a la lógica en lugar de probar la conexión/recuperación al mismo tiempo. Me pregunto si esto parece razonable para hacer cumplir como un estándar de codificación. ¿Cuáles son los pros/contras con respecto a la unidad de prueba de bases de datos en vivo/servicios web que me falta?

Answer 1

También deben probarse las partes de la base de datos y del servicio web de su aplicación, pero por definición no serán pruebas unitarias, sino pruebas de integración. Estas pruebas serían independientes de las pruebas de su unidad y se ejecutarían con menos frecuencia, pero proporcionarán una detección temprana de defectos muy valiosa.

Answer 2

Generalmente veo un unit test como algo que prueba una clase individual o módulo de forma aislada. Como tal, trato de evitar que las pruebas unitarias conozcan los sistemas en vivo o los recursos externos (tiendo a evitar tales dependencias en las pruebas unitarias) o me burlo de ellas.

Integration tests tienen una historia diferente. Una prueba de integración debe evitar burlarse de los recursos, y por lo tanto, de hecho puede requerir una base de datos en vivo o un servicio para soportarlo. Lo que está describiendo parece que puede ser una prueba de integración en lugar de una prueba unitaria.

En algunos casos, es conveniente simular los servicios que se requieren para una prueba de integración, pero cuando es posible, trato de evitar esto porque no confío en que la simulación pueda reflejar el comportamiento real. Para mí, una prueba de integración debería realmente probar la integración de componentes en un sistema.

Answer 3

IMO Probablemente falte que si utiliza bases de datos/WS en la prueba, esto no es una prueba de unidad, sino una prueba de integración.

Answer 4

Cualquier prueba de validación de compilación debe ser lo más completa posible. Si tiene una llamada a función que retransmite recursos externos, debe asegurarse de que todo el sistema se comporte correctamente.

El problema específico de las pruebas unitarias para las funciones que se conectan a una base de datos puede ser problemático porque estas funciones pueden tener efectos colaterales, como insertar datos. Estos efectos secundarios pueden hacer que los valores de retorno cambien.

Answer 5

En mi experiencia, las pruebas deben hacerse en varios niveles:

• pruebas unitarias que verifican la exactitud de las clases/módulos sin la necesidad de datos externos
• pruebas del sistema que controlan grandes partes de la aplicación , cargando datos de bases de datos/archivos específicos y verificando los resultados (por ejemplo, comparando archivos de salida).Asegúrese de no cambiar estas bases de datos/archivos y asegúrese de tener una base de datos/conjunto de archivos por grupo de pruebas
• pruebas manuales que controlan la interfaz de usuario

Cada una de estas pruebas tienen su utilidad.

Answer 6

Lo siento, pero muchos desarrolladores pasan por alto el hecho de que también necesita probar la base de datos. Puedo estar de acuerdo con burlarme de la conexión entre la clase "A" y la base de datos, pero en algún momento crearás una clase que use alguna tecnología de acceso a datos (ADO.NET, por ejemplo), y deberás probar eso realmente funciona.

Ahora, al mantener estas pruebas pequeñas y enfocadas, puede evitar más fácilmente los efectos secundarios y garantizar las condiciones iniciales correctas de la base de datos. Pero el hecho es que usted debe probar dicho código, o su lógica de negocio correctamente probada terminará con datos incorrectos para trabajar.

Answer 7

Las pruebas de unidad no se deben hacer con datos en tiempo real, punto.

Incluso si quiere comenzar a hacer pruebas de integración, tampoco empiece con datos en vivo.

Las pruebas de integración de inicio siempre deben realizarse con datos de desarrollo o de maquetas. El método preferido sería tener un sistema de desarrollo que tenga publicaciones a partir de datos en tiempo real, o usar scripts de SQL para generar un conjunto completo de datos para que los pruebes.