¿Qué es burlarse?

¿Qué es burlarse? .

Prólogo: si busca el sustantivo falso 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 en otros objetos (complejos). Para aislar el comportamiento del objeto que desea reemplazar a los otros objetos mediante simulaciones que simulan el comportamiento de los objetos reales. Esto es útil si los objetos reales no son prácticos para incorporar a la prueba unitaria.

En resumen, burlarse es crear objetos que simulan el comportamiento de objetos reales.


A veces es posible que desee distinguir entre burlarse en lugar de tropezar . Puede haber algún desacuerdo sobre este tema, pero mi definición de un stub es un objeto simulado “mínimo”. El stub implementa 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 llame al simulacro como se esperaba. Parte de la prueba es verificar que el simulacro se haya utilizado correctamente.

Para dar un ejemplo: puede resguardar una base de datos implementando una estructura simple en la memoria para almacenar registros. El objeto bajo prueba puede leer y escribir registros en el código auxiliar de la base de datos para permitirle ejecutar la prueba. Esto podría poner a prueba algún comportamiento del objeto no relacionado con la base de datos y el código auxiliar de la base de datos se incluiría solo para permitir que se ejecutara la prueba.

Si, por el contrario, desea verificar que el objeto bajo prueba escribe algunos datos específicos en la base de datos, deberá burlarse de la base de datos. Su prueba incorporaría afirmaciones sobre lo que se escribió en el simulacro de la base de datos.

Otras respuestas explican qué es burlarse. Déjame guiarte a través de este 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 para evitar probar las partes inyectadas y centrarse exclusivamente en probar el rest del código.


Digamos que está escribiendo una aplicación iOS y tiene llamadas de red. Su trabajo es probar su aplicación. Probar / identificar si las llamadas de la red funcionan o no como se espera NO ES SU RESPONSABILIDAD. Es responsabilidad de otra parte (equipo de servidor) probarlo. Debe eliminar esta dependencia (de red) y aún así 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 debe funcionar para todos ellos (en caso de errores, su aplicación arrojará el error esperado). Lo que haces con burlas es crear respuestas de red ‘imaginarias-similares a las reales’ (como un código 200 con un archivo JSON) y probar tu código sin ‘hacer una llamada de red real y esperar la respuesta de tu red’. Usted codifica / devuelve manualmente la respuesta de red para TODO tipo de respuestas de red y ve si su aplicación funciona como espera. ( nunca asumes / pruebas 200 con datos incorrectos, porque esa no es tu responsabilidad, tu responsabilidad es probar tu aplicación con 200 correctos, o en el caso de 400, 500, pruebas si tu 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 preinstaladas, ¿no?). Debe agregarle algo, insertar / insertar esa información ficticia que normalmente no es necesaria (o una parte de su clase).

Entonces subclases la clase original y agregas lo que sea (aquí la red HTTPResponse, data OR en caso de falla, pasas el errorString correcto, HTTPResponse) y luego “prueba la subclase”, es decir, la clase simulada .
Ya no prueba la clase original. El burlado / subclase se prueba en nombre de la clase original

Para resumir, burlarse es simplificar y limitar lo que está probando y también hacer que alimente de lo que depende una clase. En este ejemplo, evitas probar las llamadas a la red y, en su lugar, pruebas si tu aplicación funciona como esperas con las salidas / respuestas inyectadas , mediante clases de burla

Huelga decir que prueba cada respuesta de 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 obtener más información sobre esto: digamos que el modelo requiere una clave / campo llamado username . Usted prueba esto y sus pases de prueba. 2 semanas después, backend cambia el nombre de la clave a id . Tus pruebas aún pasan. ¿derecho? ¿o no?

¿Es la responsabilidad del desarrollador de back-end actualizar los simulacros y debería ser parte de nuestro acuerdo que proporcionen simulacros actualizados?

La respuesta al problema anterior es que: pruebas unitarias + su proceso de desarrollo como desarrollador del lado del cliente debería / debería capturar una respuesta obsoleta burlada. Si me preguntas cómo? Bueno, la respuesta es:

Nuestra aplicación real fallaría (o no fallaría pero no tendría el comportamiento deseado) sin utilizar API actualizadas … por lo tanto, si eso falla … haremos cambios en nuestro código de desarrollo. Lo cual nuevamente lleva a que nuestras pruebas fallen … y 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 … y veamos que falla y luego vamos a escribir el código de desarrollo real para él).

Todo esto significa que el backend no tiene que decir: “hey, actualizamos los simulacros” … finalmente sucede a través del desarrollo / depuración de tu código. ¡Porque todo es parte del proceso de desarrollo! Aunque si el backend te proporciona la respuesta burlada, entonces mejor.

Mi punto sobre esto no es encontrar una secuencia de comandos para obtener un simulacro actualizado de tus API, tampoco pensar que poner el 100% de tu esfuerzo en hacer las cosas a través del código es de lo que trata el TDD. Parte del proceso es la actualización manual de los JSON y la celebración de reuniones breves para garantizar que sus valores estén actualizados.

Esta sección fue escrita gracias a una discusión floja en nuestro grupo Meetup CocoaHead


Solo para desarrolladores de iOS:

Un buen ejemplo de burla es esta charla práctica orientada por protocolo de Natasha Muraschev. Solo salte al minuto 18:30.

Me gusta mucho esta parte de la transcripción:

Como esto es una prueba … queremos asegurarnos de que get Gettable la función get de Gettable , porque puede regresar y la función podría teóricamente asignar una serie de elementos de comida desde cualquier lugar . Necesitamos asegurarnos de que se llame;

Hay muchas respuestas en SO y buenas publicaciones en la web sobre burlas. Un lugar que tal vez quiera comenzar a buscar es el post de Martin Fowler Mocks Are Stubs, donde discute muchas de las ideas de la burla.

En un párrafo: burlarse es una técnica en 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 de código permitirán configurar las expectativas: un objeto simulado sabrá cómo debe ser invocado por su código y cómo responder.


Tu pregunta original mencionaba TypeMock, así que dejé mi respuesta al siguiente:

TypeMock es el nombre de un marco de burla comercial .

Ofrece todas las características de los frameworks de burla gratuitos como RhinoMocks y Moq, además de algunas opciones más potentes.

Ya sea que necesite o no TypeMock es muy debatible: puede burlarse de lo que quiera con libre burlas, y muchos argumentan que las capacidades que ofrece TypeMock a menudo lo alejarán de un diseño bien encapsulado.

Como otra respuesta declaró ‘TypeMocking’ no es realmente un concepto definido, sino que podría tomarse como el tipo de burla que ofrece TypeMock, usando el perfilador CLR para interceptar llamadas .Net en tiempo de ejecución, dando una capacidad mucho mayor para falsificar objetos (no requisitos como necesitar interfaces o métodos virtuales).

Mock es un método / objeto que simula el comportamiento de un método / objeto real de forma 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 burladas, las dependencias se comportan de la manera que las definimos.

Con las dependencias controladas por simulacros, podemos probar fácilmente el comportamiento del método que codificamos. Esta es la prueba de unidad.

¿Cuál es el propósito de los objetos simulados?

Mocks vs stubs

Pruebas unitarias vs Pruebas funcionales

El propósito de los tipos de imitación es cortar las dependencias para aislar la prueba a una unidad específica. Los talones 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 trozos y burlas.

EDITAR : Dado que la fraseología original menciona “tipo mocking”, tuve la impresión de que esto estaba relacionado con TypeMock. En mi experiencia, el término general es solo “burlarse”. Por favor, no dude en hacer caso omiso de la siguiente información específicamente en TypeMock.

TypeMock Isolator difiere de la mayoría de otros frameworks de burla 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 simularlas.

TypeMock ofrece una gran flexibilidad a expensas de un entorno de tiempo de ejecución limpio. Como efecto secundario de la forma en que TypeMock logra sus resultados, algunas veces obtendrás resultados muy extraños al usar TypeMock.

Creo que el uso del marco mocking del aislador TypeMock sería TypeMocking.

Es una herramienta que genera simulaciones para usar en pruebas unitarias, sin la necesidad de escribir su código con IoC en mente.

La burla genera pseudoobjetos que simulan el comportamiento de objetos reales para pruebas

Si su simulacro implica una solicitud de red, otra alternativa es tener un servidor de prueba real para golpear. Puede usar este servicio para generar una solicitud y respuesta para su prueba. http://testerurl.com/