Pregunta ¿Cuál es la diferencia entre un simulacro y un talón?


He leído varios artículos sobre simulacros y tropezones en las pruebas, que incluyen Las burlas de Martin Fowler no son talones, pero aún no entiendo la diferencia.


668
2017-08-11 14:19


origen


Respuestas:


Talón

Creo que la mayor distinción es un talón que ya has escrito con un comportamiento predeterminado. Por lo tanto, tendría una clase que implemente la dependencia (es decir, la clase abstracta o la interfaz más probable) a la que simule con fines de prueba y los métodos simplemente se anularán con las respuestas establecidas. No harían nada lujoso y ya habrían escrito el código resquebrajado fuera de su prueba.

Burlarse de

Un simulacro es algo que, como parte de su prueba, debe configurar con sus expectativas. Un simulacro no está configurado de manera predeterminada, por lo que tiene un código que lo hace en su prueba. Los simulacros en cierto modo se determinan en tiempo de ejecución ya que el código que establece las expectativas debe ejecutarse antes de que hagan algo.

Diferencia

Las pruebas escritas con burlas usualmente siguen un initialize -> set expectations -> exercise -> verify patrón para probar. Mientras que el talón pre-escrito seguiría una initialize -> exercise -> verify.

Semejanza

El propósito de ambos es eliminar la prueba de todas las dependencias de una clase o función para que sus pruebas estén más centradas y sean más simples en lo que intentan probar.


525
2017-08-11 14:38



Prefacio

Hay varias definiciones de objetos, que no son reales. El término general es prueba doble. Este término abarca: tonto, falso, talón, burlarse de.

Referencia

De acuerdo a Artículo de Martin Fowler:

  • Tonto los objetos se pasan pero nunca se usan. Por lo general, solo se utilizan para llenar listas de parámetros.
  • Falso los objetos en realidad tienen implementaciones que funcionan, pero generalmente toman algún atajo que los hace inadecuados para la producción (una base de datos en la memoria es un buen ejemplo).
  • Talones proporcionar respuestas predefinidas a las llamadas realizadas durante la prueba, por lo general, no responde en absoluto a nada fuera de lo programado para la prueba. Los talones también pueden registrar información sobre llamadas, como un talón de la puerta de enlace de correo electrónico que recuerda los mensajes que 'envió', o tal vez solo la cantidad de mensajes que 'envió'.
  • Mocks son de lo que estamos hablando aquí: objetos preprogramados con expectativas que forman una especificación de las llamadas que se espera que reciban.

Estilo

Mocks vs Stubs = Pruebas de comportamiento frente a pruebas estatales

Principio

De acuerdo con el principio de Prueba solo una cosa por prueba, puede haber varios talones en una prueba, pero generalmente solo hay una simulación.

Ciclo vital

Ciclo de vida de la prueba con talones:

  1. Configuración - Prepare el objeto que se está probando y sus colgantes colaboradores.
  2. Ejercicio: prueba la funcionalidad.
  3. Verificar estado: use afirma para verificar el estado del objeto.
  4. Desmontaje: limpiar los recursos.

Prueba de ciclo de vida con simulacros:

  1. Datos de configuración: prepare el objeto que se está probando.
  2. Configurar las expectativas - Preparar las expectativas en el simulacro que está siendo utilizado por el objeto primario.
  3. Ejercicio: prueba la funcionalidad.
  4. Verificar las expectativas - Verifica que se hayan invocado los métodos correctos en el simulacro.
  5. Verificar estado: use afirma para verificar el estado del objeto.
  6. Desmontaje: limpiar los recursos.

Resumen

Las pruebas de simulacros y comprobantes brindan una respuesta a la pregunta: Cual es el resultado?

Las pruebas con burlas también están interesadas en: ¿Cómo se ha logrado el resultado?


641
2017-07-23 12:18



Stub es un simple objeto falso. Solo hace que la prueba funcione sin problemas.
Mock es un trozo más inteligente. Usted verifica que su prueba pasa a través de él.


229
2017-08-11 14:33



Aquí hay una descripción de cada uno seguido de una muestra del mundo real.

  • Tonto - solo valores falsos para satisfacer el API.

    Ejemplo: Si está probando un método de una clase que requiere muchos parámetros obligatorios en un constructor que no tiene efecto en su prueba, puede crear objetos ficticios con el fin de crear nuevas instancias de una clase.

  • Falso - crear una implementación de prueba de una clase que puede tener una dependencia en alguna infraestructura externa. (Es una buena práctica que su prueba de unidad no NO en realidad, interactuar con la infraestructura externa).

    Ejemplo: Cree una implementación falsa para acceder a una base de datos, reemplácela por in-memory colección.

  • Talón - anular métodos para devolver valores codificados, también conocidos como state-based.

    Ejemplo: Tu clase de prueba depende de un método Calculate() Tomando 5 minutos para completar. En lugar de esperar 5 minutos, puede reemplazar su implementación real con un código que devuelve valores codificados; tomando solo una pequeña fracción del tiempo.

  • Burlarse de - muy parecido a Stub pero interaction-based en lugar de basado en estado. Esto significa que no esperas de Mock para devolver algún valor, pero para asumir que se realiza un orden específico de llamadas a métodos.

    Ejemplo: estás probando una clase de registro de usuario. Después de llamar Save, debe llamar SendConfirmationEmail.

Stubs y Mocks son en realidad sub tipos de Mock, ambos intercambian la implementación real con la implementación de la prueba, pero por razones diferentes y específicas.


161
2017-11-26 14:12



En el codeschool.com curso, Pruebas de rieles para zombis, dan esta definición de los términos:

Talón

Para reemplazar un método con código que devuelve un resultado especificado.

Burlarse de

Un apéndice con una afirmación de que se llama al método.

Entonces, como describió Sean Copenhaver en su respuesta, la diferencia es que los simulacros establecen expectativas (es decir, hacer afirmaciones sobre si se les llama o cómo se llaman).


152
2017-07-04 22:32



Los talones no fallan en sus pruebas, simulacro.


104
2018-04-18 20:05



Creo que la respuesta más simple y clara sobre esta pregunta se da desde Roy Osherove en su libro El arte de las pruebas unitarias (página 85)

La manera más fácil de decir que estamos tratando con un código auxiliar es observar que el código auxiliar nunca puede fallar la prueba. Afirma que los usos de la prueba siempre están en contra   la clase bajo prueba.

Por otro lado, la prueba usará un objeto simulado para verificar si el   prueba fallida o no. [...]

De nuevo, el objeto simulado es el objeto que usamos para ver si la prueba falló o no.

Eso significa que si estás haciendo afirmaciones contra el falso, significa que estás usando el falso como un simulacro, si usas el falso solo para ejecutar la prueba sin afirmarlo, estás usando el falso como un stub.


25
2017-08-24 14:06



Creo que la diferencia más importante entre ellos es sus intenciones.

Déjame intentar explicarlo en POR QUÉ stub vs. POR QUÉ se burlan

Supongamos que estoy escribiendo un código de prueba para el controlador de línea de tiempo público de mi cliente de mac twitter

Aquí está el código de muestra de prueba

twitter_api.stub(:public_timeline).and_return(public_timeline_array)
client_ui.should_receive(:insert_timeline_above).with(public_timeline_array)
controller.refresh_public_timeline
  • STUB: la conexión de red a Twitter API es muy lenta, lo que hace que mi prueba sea lenta. Sé que devolverá las líneas de tiempo, así que hice un apéndice que simula la API HTTP de Twitter, de modo que mi prueba se ejecutará muy rápido, y puedo ejecutar la prueba incluso cuando estoy desconectado.
  • MOCK: Todavía no he escrito ninguno de mis métodos de UI, y no estoy seguro de qué métodos necesito para escribir en mi objeto ui. Espero saber cómo mi controlador colaborará con mi objeto ui al escribir el código de prueba.

Al escribir simulacro, descubre la relación de colaboración de los objetos verificando que se cumplen las expectativas, mientras que el apéndice solo simula el comportamiento del objeto.

Te sugiero que leas este artículo si estás intentando saber más acerca de los simulacros: http://jmock.org/oopsla2004.pdf


17
2017-07-08 08:37



Un simulacro simplemente está probando el comportamiento, asegurándose de que se invocan ciertos métodos. Un Stub es una versión comprobable (per se) de un objeto en particular.

¿Qué quieres decir con una forma de Apple?


15
2017-08-11 14:30



Si lo comparas con la depuración:

Talón es como asegurarse de que un método devuelve el valor correcto

Burlarse de es como en realidad entrar en el método y asegurarse de que todo lo que está adentro sea correcto antes de devolver el valor correcto.


13
2017-11-08 13:29



Para ser muy claro y práctico:

Stub: Una clase u objeto que implementa los métodos de la clase / objeto que se va a falsificar y devuelve siempre lo que desea.

Ejemplo en JavaScript:

var Stub = {
   method_a: function(param_a, param_b){
      return 'This is an static result';
   }
}

Mock: Lo mismo de stub, pero agrega algo de lógica que "verifica" cuando se llama un método, por lo que puede estar seguro de que alguna implementación llama a ese método.

Como @mLevan dice imagina como ejemplo que estás probando una clase de registro de usuario. Después de llamar a Guardar, debe llamar a SendConfirmationEmail.

Un ejemplo de código muy estúpido:

var Mock = {
   calls: {
      method_a: 0
   }

   method_a: function(param_a, param_b){
     this.method_a++; 
     console.log('Mock.method_a its been called!');
   }
}

10
2018-06-25 16:56