testing - software - pruebas funcionales
¿Estoy realizando pruebas unitarias o pruebas de integración? (10)
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.
¿Es esto algo que debería hacerse en una prueba unitaria o una prueba de integración?
Gracias
Creo que es posible probar eso como una prueba unitaria, sin una base de datos real. En lugar de utilizar una interfaz real para la base de datos, reemplácela con un objeto simulado / stub / falso (el PDF mejor visualizado está aquí ).
Si escribirlo como una prueba unitaria 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.
Creo que eso debería hacerse 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.
Creo que la pregunta importante es "¿Qué DEBO hacer?"
En este caso, creo que debería ser una prueba unitaria. 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")));
}
Existen aquellos (incluido yo mismo) que tienen reglas estrictas sobre lo que constituye una prueba unitaria frente a una prueba de integración.
Una prueba no es una prueba unitaria si:
- Habla con la base de datos
- Se comunica a través de la red
- Toca el sistema de archivos
- No se puede ejecutar al mismo tiempo que cualquiera de tus otras pruebas unitarias
- Tienes que hacer cosas especiales en tu entorno (como editar archivos de configuración) para ejecutarlo
Que puede ser una forma de hacer una distinción entre lo que una prueba de unidad hará por ti usando la burla, por ejemplo, en lugar de cualquiera de los proveedores de recursos reales: sistema de archivos, db, etc.
Una prueba de integración puede verse como una prueba de muy acoplamiento de sistemas / capas de aplicaciones, 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.
Haz tu prueba y deja que otras personas pasen tiempo con la taxonomía.
Mi perspectiva es que debe categorizar la prueba según el alcance:
- Una prueba de unidad puede ejecutarse de manera independiente sin dependencias externas (Archivo IO, IO de red, Base de datos, Servicios web externos).
- Una prueba de integración puede tocar sistemas externos.
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!
Probablemente sea una prueba unitaria ... pero aquí hay una línea borrosa. 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 es más una prueba de integración.
Si su código de prueba se conecta a una base de datos real y depende de la presencia de ciertos datos (o falta de datos) para que la prueba pase, es una prueba de integración.
Usualmente prefiero probar algo como esto burlándome del componente que el "método de acceso a datos" usó 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.
esa es una prueba unitaria, por definición: está probando un solo elemento aislado del código en una ruta específica
Creo que se ha desperdiciado más tiempo discutiendo sobre qué es una unidad frente a qué es una prueba de integración que si se agregó el valor.
No me importa
Permítanme ponerlo de otra manera: si lo estuviera probando, vería dos formas de hacerlo: falsificar la base de datos devolviendo cero filas, o realmente conectarse a 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 utilizar el término "cara del desarrollador" frente a "cara al cliente" más a menudo, y hacer 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 no me parece útil.
Yo creo esto fuertemente; Me presenté antes de google en él.
¡buena suerte! ¡Háganos saber cómo va!