¿Qué es un "Stub"?

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

Una cosa que estoy dispuesto a hacer es asegurarme de que realmente asimilo lo que estoy haciendo, así que quería comprobar mi comprensión de lo que he visto hasta ahora (y pensé que sería bueno publicarlo aquí como un recurso).

¿Qué es un "Stub"?

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

Meszaros usa el término Test Double como el término genérico para cualquier tipo de objeto ficticio usado en lugar de un objeto real para propósitos de prueba. El nombre proviene de la noción de Stunt Double en las películas. (Uno de sus objetivos era evitar el uso de cualquier nombre que ya se usaba ampliamente). Meszaros luego definió cuatro tipos particulares de dobles:

• Los objetos ficticios se pasan de un lado a otro, pero nunca se utilizan. Por lo general, solo se utilizan para completar listas de parámetros.
• Los objetos falsos en realidad tienen implementaciones funcionales, pero generalmente toman algún atajo que los hace no adecuados para la producción (una base de datos en memoria es un buen ejemplo).
• Los stubs brindan respuestas almacenadas a las llamadas realizadas durante la prueba, por lo general, no responden en absoluto a nada fuera de lo programado para la prueba. Los talones también pueden registrar información sobre las 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ó'.
• Las simulaciones son de lo que estamos hablando aquí: 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 invoquen ciertos métodos y, por lo general, hacen que una prueba unitaria falle si no se cumplen sus expectativas. Los objetos stub proporcionan respuestas predefinidas (y las bibliotecas auxiliares pueden generarlas automáticamente), pero normalmente no provocan directamente que falle la prueba unitaria. Por lo general, solo se usan para que el objeto que está probando obtenga los datos que necesita para hacer su trabajo.

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 la capacidad de prueba 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 de datos, entonces se pueden agregar pruebas fácilmente, crear un nuevo stub (replicando el error de datos) y producir un código para corregir el error.

Los stubs se diferencian de los Mocks en que se utilizan para representar y probar el estado de un objeto, mientras que un Mock prueba su interacción .

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

Un "stub" o "método stub" está diseñado para ser un código de inicio o un sustituto temporal de un código aún por desarrollar. Es un código integrado generado por un IDE. Los métodos stub 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 verificando si la salida es correcta. Es importante para encontrar errores en su código.

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

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

+ --------- + ------------------------------- + ------- ------------------------ +
| | Stub | Conductor |
+ --------- + ------------------------------- + ------- ------------------------ +
| Tipo | Códigos ficticios | Códigos ficticios |
+ --------- + ------------------------------- + ------- ------------------------ +
| Usado en | Integración de arriba hacia abajo | Integración de abajo hacia arriba |
+ --------- + ------------------------------- + ------- ------------------------ +
| Propósito | Para permitir la prueba de la parte superior | Para permitir la prueba de la parte inferior |
| | niveles del código, cuando el | niveles del código, cuando el |
| | los niveles inferiores 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 |
| | | |
| | Se ha desarrollado A. | Aún queda por desarrollar.
| | B aún debe desarrollarse. B ha sido desarrollado. |
| | Por lo tanto, se utiliza stub | Por lo tanto, se utiliza el controlador |
| | en lugar de B para imitarlo. | en lugar de A para imitarlo |
| | | |
| | A ---> Stub | Conductor ---> B |
+ --------- + ------------------------------- + ------- ------------------------ +

De la diferencia entre Stub y Driver

Después de investigar un poco y basándome en los archivos de código auxiliar que enfrenté durante mi vida como codificador, diría que un archivo de código auxiliar es solo un archivo que contiene una parte o una parte de la implementación de un archivo. Ayuda a los desarrolladores a comenzar a codificar.