unit-testing - test - mockito maven
¿Qué es burlarse? (8)
Creo que el uso del marco de simulación de aislador TypeMock sería TypeMocking.
Es una herramienta que genera simulacros para su uso en pruebas unitarias, sin la necesidad de escribir su código teniendo en cuenta IoC.
¿Qué es burlarse? .
El propósito de los tipos de burla es cortar las dependencias para aislar la prueba a una unidad específica. Los apéndices son sustitutos simples, mientras que los simulacros son sustitutos que pueden verificar el uso. Un marco de burla es una herramienta que te ayudará a generar apéndices y simulacros.
EDITAR : Desde la mención original "tipo simulacro" tengo la impresión de que esto se relaciona con TypeMock. En mi experiencia, el término general es simplemente "burlón". Por favor, siéntase libre de ignorar la siguiente información específicamente en TypeMock.
El aislador TypeMock se diferencia de la mayoría de los demás marcos de simulacros en que funciona mi modificación de IL sobre la marcha. Eso le permite simular tipos e instancias que la mayoría de los otros marcos no pueden simular. Para simular estos tipos / instancias con otros marcos, debe proporcionar sus propias abstracciones y simular estas.
TypeMock ofrece una gran flexibilidad a costa de un entorno de ejecución limpio. Como efecto secundario de la forma en que TypeMock logra sus resultados, a veces obtendrás resultados muy extraños cuando uses TypeMock.
Hay muchas respuestas sobre SO y buenas publicaciones en la web sobre burlas. Un lugar en el que quizás quieras comenzar a mirar es el post de Martin Fowler Mocks No son talones, donde analiza muchas de las ideas de burla.
En un párrafo, la burla es una técnica particular para permitir la prueba de una unidad de código sin depender de las dependencias. En general, lo que diferencia a la burla de otros métodos es que los objetos simulados utilizados para reemplazar las dependencias del código permitirán establecer expectativas: un objeto simulado sabrá cómo debe ser llamado por su código y cómo responder.
Su pregunta original mencionó TypeMock, por lo que he dejado mi respuesta a continuación:
TypeMock es el nombre de un marco de burla comercial .
Ofrece todas las características de los marcos de simulacros gratuitos como RhinoMocks y Moq, además de algunas opciones más potentes.
Si necesita o no TypeMock es altamente discutible: puede hacer la mayoría de las burlas que desearía con las bibliotecas gratuitas de burlas, y muchos argumentan que las habilidades que ofrece TypeMock a menudo lo alejarán del diseño bien encapsulado.
Como otra respuesta dijo que ''TypeMocking'' no es en realidad un concepto definido, pero podría tomarse como el tipo de simulacro que ofrece TypeMock, usando el perfilador CLR para interceptar llamadas. tales como la necesidad de interfaces o métodos virtuales).
La burla está generando pseudoobjetos que simulan el comportamiento de objetos reales para las pruebas.
Mock es un método / objeto que simula el comportamiento de un método / objeto real de manera controlada. Los objetos simulados se usan en pruebas unitarias.
A menudo, un método bajo una prueba llama a otros servicios externos o métodos dentro de él. Estas se llaman dependencias. Una vez burlados, las dependencias se comportan de la forma en que las definimos.
Con las dependencias controladas por simulacros, podemos probar fácilmente el comportamiento del método que codificamos. Esta es una prueba de unidad.
Otras respuestas explican lo que es burlarse. Déjame guiarte a través de esto con un ejemplo . Y créeme, en realidad es mucho más simple de lo que piensas.
tl; dr Es una subclase de la clase original. Tiene otros datos inyectados, por lo que evita las pruebas de las partes inyectadas y se enfoca únicamente en probar el resto del código.
Supongamos que está escribiendo una aplicación iOS y tiene llamadas de red. Su trabajo es probar su aplicación. Para probar / identificar si las llamadas de la red funcionan como se espera, NO ES SU RESPONSABILIDAD. Es responsabilidad de otra parte (equipo del servidor) probarla. Debe eliminar esta dependencia (de red) y, sin embargo, continuar probando todo el código que funciona a su alrededor .
Una llamada de red puede devolver diferentes códigos de estado 404, 500, 200, 303, etc. con una respuesta JSON.
Se supone que su aplicación funciona para todos ellos (en caso de errores, su aplicación debería lanzar el error esperado). Lo que hace con la burla es crear "imaginario, similar a las respuestas de red reales (como un código 200 con un archivo JSON) y probar su código sin " hacer una llamada de red real y esperar su respuesta de red ". Codificas / devuelves manualmente la respuesta de red para TODOS los tipos de respuestas de red y ves si tu aplicación está funcionando como esperas. ( nunca asume / prueba un 200 con datos incorrectos, porque esa no es su responsabilidad, su responsabilidad es probar su aplicación con un 200 correcto, o en el caso de un 400, 500, prueba si su aplicación arroja el error correcto)
Esta creación imaginaria, similar a la real, se conoce como burla.
Para hacer esto, no puede usar su código original (su código original no tiene las respuestas preinsertadas, ¿verdad?). Debe agregarle algo, inyectar / insertar los datos ficticios que normalmente no se necesitan (o una parte de su clase).
Entonces, subclasifica la clase original y agrega lo que sea (aquí se trata de la red HTTPResponse, datos O, en caso de falla, pasa la cadena de errores correcta, HTTPResponse) que necesita y luego ''prueba la subclase'', es decir, la clase simulada .
Ya no pruebas la clase original. El simulado / subclase se prueba en nombre de la clase original
En pocas palabras, burlarse es simplificar y limitar lo que estás probando y también hacerte alimentar de lo que depende una clase. En este ejemplo, evita probar las propias llamadas de red y, en su lugar, comprueba si su aplicación funciona o no como esperaba con las salidas / respuestas inyectadas , mediante simulacros de clases
Ni que decir tiene que prueba cada respuesta de la red por separado.
Ahora, una pregunta que siempre tuve en mente fue: los contratos / puntos finales y, básicamente, la respuesta JSON de mis API se actualizan constantemente. ¿Cómo puedo escribir pruebas unitarias que tengan esto en cuenta?
Para desarrollar más sobre esto: digamos que el modelo requiere una clave / campo llamado username . Usted prueba esto y su prueba pasa. 2 semanas después, el backend cambia el nombre de la clave a id . Tus pruebas todavía pasan. ¿Correcto? ¿o no?
¿Es responsabilidad del desarrollador de back-end actualizar los simulacros? ¿Debería ser parte de nuestro acuerdo que proporcionen simulacros actualizados?
La respuesta al problema anterior es que: las pruebas unitarias + su proceso de desarrollo como desarrollador del lado del cliente debería / podría detectar una respuesta simulada desactualizada. Si me preguntas ¿cómo? Bueno, la respuesta es:
Nuestra aplicación real fallaría (o no fallaría aún sin tener el comportamiento deseado) sin usar las API actualizadas ... por lo tanto, si eso falla ... haremos cambios en nuestro código de desarrollo. Lo que de nuevo lleva a que nuestras pruebas fallen ... lo cual tendremos que corregirlo. (En realidad, si vamos a hacer el proceso TDD correctamente, no debemos escribir ningún código sobre el campo a menos que escribamos la prueba para él ... y veamos que falla y luego escribimos el código de desarrollo real para él).
Todo esto significa que el backend no tiene que decir: "hey actualizamos los simulacros" ... eventualmente sucede a través del desarrollo / depuración de su código. ّ ¡Porque todo es parte del proceso de desarrollo! Aunque si el backend proporciona la respuesta simulada para ti, entonces es más fácil.
Mi punto al respecto es que es ineficiente crear una secuencia de comandos para obtener una versión actualizada de sus API. TDD tampoco trata de poner el 100% de su esfuerzo en lograr que las cosas se realicen de forma automática y sin ninguna interacción humana. Parte del proceso son las actualizaciones manuales de JSON y tener reuniones breves para asegurarse de que sus valores estén actualizados.
Esta sección fue escrita gracias a una discusión relajada en nuestro grupo de reuniones CocoaHead
Solo para desarrolladores de iOS:
Un muy buen ejemplo de burla es esta conversación práctica orientada hacia el protocolo de Natasha Muraschev. Salta al minuto 18:30.
Me gusta mucho esta parte de la transcripción:
Debido a que esto es una prueba ... queremos asegurarnos de que
getGettablela funcióngetdeGettable, porque puede regresar y la función podría, en teoría, asignar una variedad de alimentos desde cualquier lugar . Tenemos que asegurarnos de que se llama;
Prólogo: Si busca el sustantivo simulado en el diccionario, encontrará que una de las definiciones de la palabra es algo hecho como una imitación .
La burla se usa principalmente en pruebas unitarias. Un objeto bajo prueba puede tener dependencias de otros objetos (complejos). Para aislar el comportamiento del objeto que desea reemplazar los otros objetos por simulacros que simulan el comportamiento de los objetos reales. Esto es útil si los objetos reales no son prácticos para incorporar en la prueba de la unidad.
En resumen, la burla es crear objetos que simulan el comportamiento de objetos reales.
A veces es posible que desee distinguir entre burlarse en lugar de aplastar . Puede haber algún desacuerdo sobre este tema, pero mi definición de stub es un objeto simulado "mínimo". El código auxiliar implementa solo el comportamiento suficiente para permitir que el objeto bajo prueba ejecute la prueba.
Un simulacro es como un talón, pero la prueba también verificará que el objeto bajo prueba llama al simulacro como se esperaba. Parte de la prueba es verificar que el simulacro se usó correctamente.
Para dar un ejemplo: puede apilar una base de datos implementando una estructura simple en memoria para almacenar registros. El objeto bajo prueba puede leer y escribir registros en el apéndice de la base de datos para permitir que ejecute la prueba. Esto podría probar algún comportamiento del objeto no relacionado con la base de datos y el apéndice de la base de datos se incluiría solo para permitir que se ejecute la prueba.
Si, en cambio, desea verificar que el objeto bajo prueba escribe algunos datos específicos en la base de datos, tendrá que burlarse de la base de datos. Su prueba incorporaría aseveraciones sobre lo que se escribió en la base de datos simulada.
Si su simulacro implica una solicitud de red, otra alternativa es tener un servidor de prueba real para golpear. Puede utilizar este servicio para generar una solicitud y respuesta para sus pruebas. http://testerurl.com/