A menudo se dice que las interfaces hacen que el burlarse y probar las unidades sea un proceso más fácil. ¿Cómo ayudan las interfaces con esto?¿Cómo hacen las interfaces para facilitar las pruebas unitarias y las burlas?
Es la naturaleza de las interfaces a proporcionar muchas implementaciones, por lo tanto, permiten burlarse de.
Especialmente en las pruebas de integración, puede dar su versión de una maqueta del sistema de dependencia (por ejemplo, un servicio web). En lugar de activar realmente un sistema dependiente o incluso un módulo, o una complicado y difícil de crear una instancia de tipo, puede proporcionar una implementación de la interfaz más simple que proporcionará resultados necesarios para la prueba de la unidad para completar correctamente.
Además de eso, cuando se utiliza en la unidad de pruebas, un real depende tipo (llámese BigGraph) escondido en un modelo de objetos complicados detrás de él, que son, de hecho, hacer las pruebas de integración, no la unidad de pruebas. Su prueba se puede romper fácilmente si hay un error en cualquiera de los tipos dependientes (BigGraph), no del tipo que está probando, por lo tanto no es una prueba unitaria. El uso de las maquetas reduce el riesgo de que suceda.
He visto muchos sistemas de integración continuos que muestran docenas de errores para un error, cuando deberían aparecer uno, o como mucho un par, todos debido a modelos de objetos demasiado complicados y pruebas de unidad incorrectamente escritas, sin usar maquetas.
Hoy en día, los marcos de burla son más sofisticados (modificación del código de bytes, etc.) que en los viejos tiempos, por lo que a veces las interfaces o incluso los métodos virtuales no siempre son necesarios, pero las interfaces sin núcleo lo permiten.
Las interfaces no ayudarán si su modelo de objetos es demasiado complicado y desordenado (por ejemplo, la interfaz se basa en gran medida de otros tipos/interfaces); luego implementando/burlándose de todo esto es un dolor.
Si no está obligado a una implementación concreta, puede cambiar comportamientos detrás de una interfaz.
Si sus clases implementan interfaces, los comportamientos pueden ser burlados.
Por ejemplo, no necesita enviar correo no deseado a todos sus clientes en su base de datos para comprobar si su algoritmo de notificación de correo funciona. Creará un simulacro para su interfaz IMailSender y solo contará la cantidad de correos electrónicos enviados. Luego, probará la implementación real que realmente está enviando los correos electrónicos en una sola dirección de correo electrónico y sabrá que todo el proceso de notificación funciona.
En este ejemplo particular, la prueba utiliza un simulacro que implementa IMailSender que solo cuenta los correos electrónicos enviados y su código de producción real utilizará una implementación que implementa IMailSender que realmente envía los correos electrónicos a través del servidor SMTP.
Si tiene varios objetos que tienen una implementación diferente pero ofrecen los mismos métodos al exterior, compartir las mismas interfaces le permite escribir una prueba de unidad y ejecutarla contra todas las implementaciones.
Si tiene una clase que dice publicar cosas en la web back-end y luego recupera una prueba de unidad de prueba que sería problemática, porque una conexión a Internet fallida podría permitir que la prueba falle. Por lo tanto, define una interfaz para esta clase y luego puede escribir una segunda implementación que registra las cosas que deben enviarse y entrega la respuesta correcta. De esta forma, puede probar las clases que funcionan con la respuesta desde la parte de atrás sin depender de una conexión a Internet durante el tiempo de ejecución de la prueba.
Si usted tiene una clase, puede tener un montón de dependencias como
constructores Insane (un montón de argumentos, o se necesita un poco de otra clase que necesita una tercera clase que necesita una cuarta clase que necesita una conexión de base de datos válida)
utilizar la clase de alguna manera, debe inicializar correctamente (por ejemplo, debe pasar algunos otros objetos que deben ser válidos, también)
la clase tiene una estado. Este estado puede cambiar durante la prueba por algún motivo.
La clase podría tener o utilizar los campos estáticos
Estas dependencias son generalmente irrelevantes durante muchas de sus pruebas y que preferiría no tener que lidiar con ellos.
Con una interfaz, puede crear una clase simulada simple que solo implementa los pocos métodos que necesita. La mayoría de los frameworks burlones tienen soporte incorporado para esto. "Implementar" aquí generalmente significa "devolver un valor fijo". De esta manera, puede construir rápidamente el entorno que necesita la clase bajo prueba.
Así, por ejemplo, si su clase necesita leer registros de una base de datos, puede en cambio simular un ResultSet que simplemente devuelve las filas. Por lo tanto, no tiene que tener una base de datos real, no necesita crear una conexión (que es lenta y puede fallar por muchas razones), no tiene que preocuparse por los datos en la base de datos (por lo tanto, no debe no tiene que eliminar/eliminar tablas y volver a llenarlas con datos de prueba), etc.
Al probar el comportamiento que cruza un puerto, tener una interfaz para el adaptador ayudará a poder inyectar una implementación diferente durante la prueba (es decir, test double).
Por ejemplo, un DAO que llama a una base de datos o un servicio web podría ser reemplazado por una implementación que devuelva datos trozados.
Consulte esta explicación de los simulacros dinámicos: http://stackoverflow.com/questions/1972831/to-mock-an-object-does-it-have-to-be-either-implementing-an-interface-or- marcado/1973482 # 1973482 –