¿Es una mala práctica ejecutar pruebas en una base de datos en lugar de en repositorios falsos?

Question

Sé cuáles son las ventajas y uso datos falsos cuando trabajo con sistemas más complejos.

¿Qué pasa si estoy desarrollando algo simple y puedo configurar fácilmente mi entorno en una base de datos real y los datos a los que se accede son tan pequeños que el tiempo de acceso no es un factor, y solo estoy realizando algunas pruebas?

¿Sigue siendo importante crear datos falsos o puedo olvidar la codificación adicional y saltar directamente a la realidad?

Cuando dije una base de datos real, no me refiero a una base de datos de producción, me refiero a una base de datos de prueba, sino a un DBMS real y al mismo esquema que la base de datos real.

Answer 1

Las razones para usar datos falsos en lugar de una base de datos real son:

1. velocidad. Si tus pruebas son lentas no las vas a ejecutar. Burlarse de la base de datos puede hacer que sus pruebas se ejecuten mucho más rápido de lo que podrían hacerlo.
2. Control. Sus pruebas deben ser la única fuente de sus datos de prueba. Cuando usas datos falsos, tus pruebas eligen qué falsificaciones usarás. Por lo tanto, no hay posibilidad de que sus pruebas se echen a perder porque alguien dejó el DB en un estado desconocido.
3. Orden Independencia. Queremos que nuestras pruebas sean ejecutables en cualquier orden. La entrada de una prueba no debe depender de la salida de otra prueba. Cuando sus pruebas controlan los datos de las pruebas, éstas pueden ser independientes entre sí.
4. Independencia del medio ambiente. Sus pruebas deben ser ejecutables en cualquier entorno. Debe poder correrlos mientras está en el tren, en un avión, en su casa o en el trabajo. No deben depender de servicios externos. Cuando usas datos falsos, no necesitas un DB externo.

Ahora, si está construyendo una pequeña aplicación, y al usar una base de datos real (como MySQL) puede lograr los objetivos anteriores, entonces, por supuesto, use la base de datos. Hago. Pero no se equivoque, a medida que su aplicación crezca, eventualmente se enfrentará a la necesidad de burlarse de la base de datos. Está bien, hazlo cuando lo necesites. YAGNI. Solo asegúrate de HACERLO CUANDO lo necesites. Si lo dejas pasar, pagarás.

Answer 2

Depende de lo que quieras probar. A menudo, desea probar la lógica real en su código, no los datos en la base de datos, por lo que configurar una base de datos completa solo para ejecutar sus pruebas es una pérdida de tiempo.

También considere la cantidad de trabajo que se dedica a mantener sus pruebas y su base de datos de prueba. Probar su código con una base de datos a menudo significa que está probando su aplicación en conjunto en lugar de las diferentes partes aisladas. Esto a menudo resulta en mucho trabajo manteniendo sincronizados tanto la base de datos como las pruebas.

Y el último problema es que la prueba debe ejecutarse de forma aislada, por lo que cada prueba debe ejecutarse en su propia versión de la base de datos o dejarla exactamente en el mismo estado en que se encontraba antes de que se ejecutara la prueba. Esto incluye el estado después de una prueba fallida.

Habiendo dicho eso, si realmente quieres probar en tu base de datos, puedes hacerlo. Existen herramientas que ayudan a configurar y destruir una base de datos, como dbunit .

He visto gente tratando de crear una prueba de unidad como esta, pero casi siempre resulta ser mucho más trabajo de lo que realmente vale la pena. La mayoría lo abandonó a mitad de camino durante el proyecto, la mayoría abandonó ttd completamente durante el proyecto, pensando que la experiencia se transfirió a la prueba de unidad en general.

Por lo tanto, recomendaría mantener las pruebas simples y aisladas y encapsular su código lo suficientemente bien como para que sea posible probar su código de forma aislada.

Answer 3

Creo que depende de si sus consultas están arregladas dentro del repositorio (la mejor opción, IMO), o si el repositorio expone las consultas compuestas; por ejemplo, si tiene un método de repositorio:

IQueryable<Customer> GetCustomers() {...}

Entonces tu UI podría solicitar:

var foo = GetCustomers().Where(x=>SomeUnmappedFunction(x));

bool SomeUnmappedFunction(Customer customer) {
   return customer.RegionId == 12345 && customer.Name.StartsWith("foo");
}

Esto pasará para un repositorio falso basado en objetos, pero fallará para las implementaciones de db de actual . Por supuesto, puede anular esto haciendo que el repositorio maneje todas las consultas internamente (sin composición externa); por ejemplo:

Customer[] GetCustomers(int? regionId, string nameStartsWith, ...) {...}

Debido a que esto no se puede componer, puede verificar el DB y la interfaz de usuario de forma independiente. Con las consultas compuestas, se le obliga a usar las pruebas de integración en todo momento si desea que sean útiles.

Answer 4

Depende de si la base de datos está configurada automáticamente por la prueba, también si la base de datos está aislada de otros desarrolladores.

En este momento puede que no sea un problema (por ejemplo, solo un desarrollador). Sin embargo (para la configuración manual de la base de datos) la configuración de la base de datos es un impedimento adicional para ejecutar pruebas, y esto es algo muy malo.

Answer 5

Si solo está escribiendo una aplicación única que sabe que no crecerá, creo que hay muchas "mejores prácticas". simplemente ve por la ventana.

No necesita para utilizar DI / IOC o para realizar pruebas unitarias o simular su acceso a la base de datos si todo lo que está escribiendo es un simple " Póngase en contacto con nosotros " formar. Sin embargo, donde dibujar la línea entre un " simple " aplicación y un " complejo " uno es dificil.

En otras palabras, use su mejor criterio, ya que no hay una respuesta definitiva para esto.

Answer 6

Está bien hacer eso para el escenario, siempre que no los veas como " unidad " pruebas Esas serían las pruebas de integración. También debe considerar si va a realizar una prueba manual a través de la interfaz de usuario una y otra vez, ya que podría automatizar sus pruebas de humo. Teniendo en cuenta eso, incluso podría considerar no realizar las pruebas de integración en absoluto, y simplemente trabajar en el nivel de pruebas funcionales / ui (ya que ya cubrirán la integración).

Como han señalado otros, es difícil trazar la línea en complejo / no complejo, y normalmente lo harías ahora cuando sea demasiado tarde :(. Si ya estás acostumbrado a hacerlo, estoy seguro de que lo ganarás ' No hay muchos gastos generales. Si ese no fuera el caso, podrías aprender de ello :)

Answer 7

En la medida en que el Real DB no se interponga en su camino, y usted puede ir más rápido de esa manera, sería pragmático y lo haría.

En prueba de unidad, la prueba " prueba " es más importante que la " unidad " ;.

Answer 8

Suponiendo que desea automatizar esto, lo más importante es que puede generar su condición inicial mediante programación. Parece que ese es el caso, e incluso mejor, estás probando datos del mundo real.

Sin embargo, hay algunos inconvenientes:

Es posible que su base de datos real no cubra ciertas condiciones en su código. Si tienes datos falsos, haces que se produzca ese comportamiento.

Y como señala, tiene una aplicación simple; cuando sea menos sencillo, querrá tener pruebas que pueda clasificar como pruebas unitarias y pruebas del sistema. Las pruebas unitarias deben apuntar a una pieza simple de funcionalidad, que será mucho más fácil de hacer con datos falsos.

Answer 9

Una de las ventajas de los repositorios falsos es que su prueba de regresión / unidad es consistente, ya que puede esperar los mismos resultados para las mismas consultas. Esto facilita la creación de ciertas pruebas unitarias.

Hay varias desventajas si su código (si no es solo consulta de lectura) modifica los datos: - Si tiene un error en su código (que es probablemente el motivo por el que realiza las pruebas), podría terminar rompiendo la base de datos de producción. Incluso si no lo rompiste. - Si la base de datos de producción cambia con el tiempo y, especialmente, mientras se ejecuta su código, puede perder la pista de los materiales de prueba que agregó y tener dificultades más tarde para eliminarlo de la base de datos. - Las consultas de producción de otros sistemas que acceden a la base de datos pueden tratar sus datos de prueba como datos reales y esto puede corromper los resultados de procesos de negocios importantes en el futuro. Por ejemplo, incluso si marcó sus datos con una determinada bandera o prefijo, ¿puede garantizar que cualquier persona que acceda a la base de datos se adherirá a este esquema?

Además, algunas bases de datos están reguladas por las leyes de privacidad, por lo que, dependiendo de su contrato y de quién es el propietario de la base de datos principal, puede o no tener acceso legal a los datos reales.

Si necesita ejecutar en una base de datos de producción, le recomendaría que se ejecute en una copia que puede crear fácilmente durante las horas pico.

Answer 10

Es una aplicación realmente simple, y no puedes verla crecer, no veo ningún problema al ejecutar tus pruebas en una base de datos real. Sin embargo, si cree que esta aplicación crecerá, es importante que lo tenga en cuenta en sus pruebas.

Mantenga todo lo más simple que pueda, y si después necesita pruebas más flexibles, hágalo. Sin embargo, planifique con anticipación, ya que no desea tener una aplicación enorme en 3 años que se basa en pruebas antiguas y piratas (para una aplicación grande).

Answer 11

Las desventajas de ejecutar pruebas en su base de datos son la falta de velocidad y la complejidad para configurar el estado de su base de datos antes de ejecutar pruebas.

Si tiene control sobre esto, no hay problema en ejecutar las pruebas directamente contra la base de datos; En realidad, es un buen enfoque porque simula su producto final mejor que ejecutarse contra datos falsos. La clave es tener un enfoque pragmático y ver las mejores prácticas como directrices y no como reglas.