Estoy empezando con las pruebas automáticas y me gustaría probar uno de mis métodos de acceso a datos. Estoy tratando de probar lo que hace el código si la base de datos no devuelve ningún registro.¿Pruebas unitarias o pruebas de integración?
¿Esto es algo que debería hacerse en una prueba de unidad o una prueba de integración?
Gracias
Si su código de prueba se conecta a una base de datos real y se basa en la presencia de ciertos datos (o falta de datos) para pasar la prueba, se trata de una prueba de integración.
Por lo general, prefiero probar algo así burlándose del componente que utiliza el "método de acceso a datos" para obtener los datos reales, ya sea una conexión JDBC o un proxy del servicio web o cualquier otra cosa. Con un simulacro, dices "cuando se llama a este método, devuelve esto" o "asegúrate de que este método se llame N veces", y luego le dices a la clase bajo prueba que use el componente simulado en lugar del componente real. Esto entonces es una "prueba de unidad", porque está probando cómo se comporta la clase bajo prueba, en un sistema cerrado donde ha declarado exactamente cómo se comportarán los otros componentes. Has aislado la clase bajo prueba por completo y puedes estar seguro de que los resultados de tus pruebas no serán volátiles y dependerán del estado de otro componente.
No estoy seguro de qué idioma/tecnología está trabajando, pero en el mundo de Java, puede usar JMock, EasyMock, etc. para este propósito.
Lo más probable es una prueba de unidad ... pero hay una línea borrosa aquí. Realmente depende de la cantidad de código que se está ejecutando: si está contenido en una biblioteca o clase, entonces su prueba unitaria, si abarca varios componentes, entonces se trata más de una prueba de integración.
Creo que se debe hacer en una prueba unitaria. No está probando que puede conectarse a la base de datos, o que puede llamar a sus procedimientos almacenados ... está probando el comportamiento de su código.
Podría estar equivocado, pero eso es lo que creo, a menos que alguien me dé una razón para pensar lo contrario.
Haz tu prueba y deja que otras personas pasen tiempo con la taxonomía.
Creo que la diferencia es importante, porque le ayuda a decidir cómo escribirla, quién debe escribirla, dónde debe vivir, cuándo debe ejecutarse y cómo deben manejarse las fallas. Pero eso no es excusa para empantanarse. Votado arriba. –
Saber qué pruebas de integración vs pruebas unitarias pueden ayudarlo a encontrar buenos marcos, herramientas o mejores prácticas para esa tarea específica. ¡Esta pregunta fue útil! –
Creo que es posible probar eso como una prueba de unidad, sin una base de datos real. En lugar de utilizar una interfaz real para la base de datos, reemplácela con un mock/stub/fake object (el PDF mejor visualizado es here).
Si escribirlo como una prueba de unidad resulta ser demasiado difícil, y no puede refactorizar el código de que probarlo sería fácil, entonces será mejor que lo escriba como una prueba de integración. Se ejecutará más despacio, por lo que es posible que no pueda ejecutar todas las pruebas de integración después del cambio de código (a diferencia de las pruebas unitarias que puede ejecutar cientos y miles por segundo), pero siempre que se ejecuten regularmente (por ejemplo, como parte de integración continua), producen algún valor.
Existen aquellos (yo incluido) que tienen reglas estrictas sobre lo que constituye una prueba unitaria frente a una prueba de integración.
Una prueba is not a unit test si:
que puede ser una manera de hacer una distinción entre lo que es una prueba de la unidad va a hacer para usted, utilizando burla por ejemplo, en lugar de cualquiera de los proveedores de recursos reales - sistema de ficheros, etc. db
una prueba de integración puede ser visto como una prueba de muy acoplamiento de sistemas/capas de aplicación, por lo que los fundamentos se prueban en la unidad y la interoperabilidad del sistema es el foco de una prueba de integración.
Sin embargo, sigue siendo un área gris porque a menudo se pueden identificar ciertas excepciones a este tipo de reglas.
Creo que la pregunta importante es "¿Qué DEBERÍA estar haciendo?"
En este caso, creo que debería someterse a pruebas unitarias. Simula el código que habla con el DB y haz que devuelva un resultado confiable (sin filas), de esta manera tu prueba verifica lo que sucede cuando no hay filas, y no lo que sucede cuando el DB devuelve lo que está en el DB en el punto prueba.
Definitivamente la unidad lo prueba!
[TestMethod]
public void ForgotMyPassword_SendsAnEmail_WhenValidUserIsPassed()
{
var userRepository = MockRepository.GenerateStub<IUserRepository>();
var notificationSender = MockRepository.GenerateStub<INotificationSender>();
userRepository.Stub(x => x.GetUserByEmailAddressAndPassword("[email protected]", "secret")).Return(new User { Id = 5, Name = "Peter Morris" });
new LoginController(userRepository, notificationSender).ResendPassword("[email protected]", "secret");
notificationSender.AssertWasCalled(x => x.Send(null),
options => options.Constraints(Text.StartsWith("Changed")));
}
que es una prueba de unidad, por definición: se está probando un solo elemento aislado del código en una ruta específica
Mi perspectiva es que se debe clasificar la prueba basada en el alcance:
Si la prueba requiere la ejecución de una base de datos real, llámela una prueba de integración y manténgala separada de las pruebas unitarias. Esto es importante porque si se mezclan las pruebas de integración y unidad, se hace que el código sea menos sostenible.
Un conjunto mixto de pruebas significa que los nuevos desarrolladores pueden necesitar un montón de dependencias externas para ejecutar el conjunto de pruebas. Imagine que desea realizar un cambio en un fragmento de código relacionado con la base de datos, pero que en realidad no requiere que la base de datos funcione, se sentirá frustrado si necesita una base de datos solo para ejecutar las pruebas asociadas con el proyecto.
Si la dependencia externa es difícil de simular (por ejemplo, en DotNet, si está utilizando Rhino Mocks y las clases externas no tienen interfaces), cree una clase de envoltura delgada que toque el sistema externo. Luego burla esa envoltura en las pruebas de la unidad. ¡No debería necesitar una base de datos para ejecutar esta prueba simple, así que no necesita una!
Creo que se ha desperdiciado más tiempo argumentando acerca de qué es una unidad frente a qué es una prueba de integración que se ha agregado el valor.
No me importa.
Permítanme decirlo de otra manera: si lo estuviera probando, vería dos formas de hacerlo: falsifique la base de datos devolviendo cero filas, o conecte con una base de datos que no tenga datos para la selección. Probablemente comenzaría a probar con lo que sea más fácil de hacer y más simple de implementar, si se ejecutó lo suficientemente rápido como para poder obtener comentarios significativos. Entonces consideraría al otro si lo necesitara para correr más rápido o si pensé que habría alguna ventaja.
Por ejemplo, probablemente comenzaría a conectarme al DB de prueba real en mi trabajo. Pero si el software necesitaba trabajar con muchas bases de datos diferentes -Oracle, PostGres, MySQL, SQL Server y DB, o si el DB de prueba en el trabajo estaba inactivo para 'refrescar' mucho, probablemente escribiría el 'pure/unit' prueba que existió totalmente aislada.
En mi vejez, prefiero usar el término "cara del desarrollador" frente a "cara al cliente" más a menudo, y hago el tipo de prueba que tiene más sentido. Creo que usar términos como "unidad" extensamente, y luego obtener una definición-weenie acerca de ello lleva a personas que hacen cosas como burlarse del sistema de archivos o burlarse de captadores y establecedores, actividad que considero inútil.
Creo esto fuertemente; Me presenté antes de google en él.
buena suerte! ¡Háganos saber cómo va!
Pensar en "pruebas unitarias" en el sentido de "sistema cerrado" es muy útil para diferenciarlo de las "pruebas de integración". – hurikhan77