it-swarm.dev

¿Qué es un "talón"?

Entonces, continuando con mi resolución de año nuevo para obtener más en TDD, ahora estoy empezando a trabajar más con Rhino Mocks .

Una cosa que quiero hacer es asegurarme de que realmente me quejo de lo que recibo, así que quise comprobar mi comprensión de lo que he visto hasta ahora (y pensé que sería bueno tenerlo aquí como un recurso).

¿Qué es un "talón"?

107
Rob Cooper

Martin Fowler escribió un excelente artículo sobre este tema. De ese artículo:

Meszaros usa el término doble de prueba como el término genérico para cualquier tipo de objeto ficticio utilizado en lugar de un objeto real con fines de prueba. El nombre proviene de la noción de Stunt Double en las películas. (Uno de sus objetivos era evitar usar cualquier nombre que ya se usara ampliamente). Meszaros definió cuatro tipos particulares de doble:

  • Los objetos ficticios se pasan pero nunca se usan. Por lo general, sólo se utilizan para rellenar las listas de parámetros.
  • Los objetos falsos realmente tienen implementaciones de trabajo, pero usualmente toman algún atajo que los hace no adecuados para la producción (un buen ejemplo es una base de datos en memoria).
  • Los apéndices proporcionan respuestas enlatadas a las llamadas realizadas durante la prueba, por lo general, no responden en absoluto a nada fuera de lo que está programado para la prueba. Los stubs también pueden registrar información sobre las llamadas, como un stub de pasarela de correo electrónico que recuerda los mensajes que "envió", o tal vez solo la cantidad de mensajes que "envió".
  • Aquí estamos hablando de simulacros: objetos preprogramados con expectativas que forman una especificación de las llamadas que se espera que reciban.

Para decirlo con mis propias palabras: los objetos simulados "esperan" que se invocen ciertos métodos y, por lo general, hacen que una prueba de unidad falle si no se cumplen sus expectativas. Los objetos de código auxiliar proporcionan respuestas enlatadas (y pueden ser generadas automáticamente por las bibliotecas auxiliares), pero normalmente hacen no causan que la prueba de la unidad falle. Por lo general, solo se utilizan para que el objeto que está probando obtenga los datos que necesita para hacer su trabajo.

95
Ross

Un "stub" es una implementación de una interfaz que existe para proporcionar datos/una respuesta de algún tipo. Por ejemplo:

  • un conjunto de datos
  • lista de usuarios
  • un archivo xml

Normalmente esto lo proporcionaría otro servicio (ya sea un servicio web, otra aplicación, una base de datos), pero para mejorar el verificabilidad del código, los resultados son "falsos".

Un beneficio importante de esto es que permite hacer afirmaciones en pruebas unitarias basadas en los datos esperados. Si surgen errores debido a errores en los datos, entonces las pruebas se pueden agregar fácilmente, se creará un nuevo código auxiliar (replicando el error en los datos) y se generará un código para corregir el error.

Apéndices difieren de Simulacros en que se usan para representar y probar el estado de un objeto, mientras que un simulacro prueba su interacción.

28
Rob Cooper

Creo que "stub" viene de STartUpBlock. se usa para referirse a partes de código que se generan automáticamente para ayudarlo a usted, el desarrollador, a comenzar.

7
Kris

Un "código auxiliar" o "método de código auxiliar" está diseñado para ser un código de inicio o un sustituto temporal del código aún por desarrollar. Es un código incorporado generado por un IDE. Los métodos de código auxiliar son en realidad métodos utilizados para probar métodos de una clase en particular. Se usa ingresando algunos valores para las variables locales en sus métodos de desarrollo reales y verifique si la salida es correcta. Es importante para encontrar errores en su código.

2
Nasserr

Me enfrenté a la pregunta recientemente y reconocí que esta comparación entre Stub y Driver es realmente clara y útil:

Básicamente, los apéndices y los controladores son rutinas que en realidad no hacen nada excepto declararse a sí mismos y los parámetros que aceptan. El resto del código puede tomar estos parámetros y usarlos como entradas.

 + --------- + ------------------------------- + - ----------------------------- + 
 | | Talón | Conductor | 
 + --------- + ------------------------------- ------------------------------- + 
 | Tipo | Códigos ficticios | Códigos ficticios | 
 + --------- + ------------------------------- + ------------------------------- + 
 | Utilizado en | Integración Top Down | Integración de abajo hacia arriba | 
 + --------- + ------------------------------ - + ------------------------------- + 
 | Proposito Para permitir la prueba de la parte superior | Para permitir la prueba de la baja | 
 | | niveles del código, cuando el | niveles del código, cuando el [
 | | los niveles más bajos del código son | los niveles superiores del código son | 
 | | aún no desarrollado. | aún no desarrollado. | 
 + --------- + ------------------------------- + - ------------------------------ + 
 | Ejemplo | A y B son componentes. | A y B son componentes. | 
 | | A ---> B | A ---> B | 
 | | | | 
 | | A se ha desarrollado. | Aún se necesita desarrollar una. | 
 | | B aún necesita ser desarrollado. B ha sido desarrollado. | 
 | | Por lo tanto, se utiliza talón | Por lo tanto, se utiliza el controlador | 
 | | En lugar de B para imitarlo. | en lugar de A para imitarlo | 
 | | | | 
 | | A ---> Stub | Conductor ---> B | 
 + --------- + --------------------------- ---- + ------------------------------- + 

De Diferencia entre Stub y Driver

1
Vahid Hallaji

Después de algunas investigaciones y en base a los archivos de resguardo que enfrenté durante mi vida como codificador, diría que un archivo de apéndice es solo un archivo que contiene una parte o la totalidad de la implementación de un archivo. Ayuda a los desarrolladores a comenzar a codificar.

0
Deric Lima