¿Por qué escribimos objetos simulados al escribir casos de prueba unitarios?

Actualmente estamos escribiendo casos de prueba de unidad en nuestro proyecto. Las implementaciones para los métodos de base de datos existen y están funcionando bien. En este caso, ¿por qué necesitamos escribir objetos simulados? ¿Hay alguna razón específica? ¿Por qué no puedo probar la implementación DAO directamente?

No debes burlarte de las llamadas a la base de datos porque eso sería contrario al propósito. Lo que DEBE burlarse son, por ejemplo, las llamadas a su DAO desde, por ejemplo, una capa de servicio. La burla te permite probar métodos de forma aislada.

Digamos que tiene una simulación de restaurante con una arquitectura como esta:

Cook <=> Server <=> Customer

Desea probar cada capa de forma independiente. Aquí Serverestá su capa de servicio y Cookpuede considerarse como un DAO. Esto Serveres lo que quiere burlarse durante la prueba Customer, y Cookes lo que quiere burlarse durante la prueba Server. Las Cookpruebas de unidad, sin embargo, deben verificar que la aplicación está volviendo una hamburguesa cuando una hamburguesa fue ordenado y no un neumático de caucho.

Está perfectamente bien probar businesslogic junto con la base de datos. pero estas pruebas se llaman pruebas de integración incluso si usa nunit o junit o phpunit para ejecutarlas.

Las pruebas unitarias son pruebas especializadas en las que las pruebas de forma aislada (es decir, lógica de negocios sin la base de datos) son importantes. Simulacros / falsificaciones / stups se utilizan para imponer este aislamiento.

Simplemente: para probar el DAO real y no el contenido de la base de datos.

Supongamos que su clase DAO Person tiene un método getByName (). Escribe una prueba y llama a Person.getByName ("John Smith"). Supongamos que la prueba falla, porque alguien eliminó el registro de John de la base de datos. Ahora, cada software de CI y sus supervisores / revisores pueden afirmar que su software es defectuoso, mientras que en realidad no lo es. Si se burla de DB, puede probar que su DAO funciona si se le da la fila correcta de la tabla correcta.

Si realmente desea probar la base de datos, es decir: si la ejecución de cierto método DAO coloca los datos en un estado determinado, entonces también es posible. Además, es realmente útil con modelos de datos extravagantes (EAV, conjunto de árboles anidados) donde no se puede esperar que la base de datos proporcione integridad a prueba de balas. Echa un vistazo a DBUnit para hacerte la vida más fácil.

Otra razón es evitar el tiempo de ejecución de ejecutar realmente los comandos de la base de datos. Puede que no parezca mucho, pero la sobrecarga de configurar y derribar conexiones eventualmente se sumarán y probablemente aumentarán significativamente el tiempo general para ejecutar el conjunto de pruebas en comparación con el uso de objetos simulados.

Para aislar la clase que está probando. O bien, si la prueba falla, ¿cómo sabe que el problema está en la clase que está probando o en una de sus dependencias?