api - significado - stub method
¿Qué significa "to stub" en la programación? (6)
En este contexto, la palabra "stub" se usa en lugar de "mock", pero en aras de la claridad y precisión, el autor debería haber usado "mock", porque "mock" es una especie de stub, pero para la prueba. Para evitar mayor confusión, necesitamos definir qué es un stub.
En el contexto general, un stub es una parte del programa (generalmente una función o un objeto) que encapsula la complejidad de invocar a otro programa (generalmente ubicado en otra máquina, máquina virtual o proceso, pero no siempre, también puede ser local objeto). Debido a que el programa real a invocar generalmente no se encuentra en el mismo espacio de memoria, invocarlo requiere muchas operaciones como direccionamiento, realizar la invocación remota real, ordenar / serializar los datos / argumentos a pasar (y lo mismo con el resultado potencial), tal vez incluso tratar con la autenticación / seguridad, y así sucesivamente. Tenga en cuenta que en algunos contextos, los resguardos también se denominan proxies (como los proxies dinámicos en Java).
Un simulacro es un tipo de trozo muy específico y restrictivo, porque un simulacro es un reemplazo de otra función u objeto para probar. En la práctica, a menudo utilizamos simulaciones como programas locales (funciones u objetos) para reemplazar un programa remoto en el entorno de prueba. En cualquier caso, la simulación puede simular el comportamiento real del programa reemplazado en un contexto restringido.
La mayoría de los tipos de stubs famosos son obviamente para programación distribuida, cuando necesitan invocar procedimientos remotos ( RPC ) u objetos remotos ( RMI , CORBA ). La mayoría de las bibliotecas / marcos de programación distribuidos automatizan la generación de talones para que no tenga que escribirlos manualmente. Los stubs se pueden generar a partir de una definición de interfaz, escrita con IDL por ejemplo (pero también puede usar cualquier idioma para definir interfaces).
Normalmente, en RPC, RMI, CORBA, etc., se distinguen los apéndices del lado del cliente , que en su mayoría se encargan de ordenar / serializar los argumentos y realizar la invocación remota, y los apéndices del servidor , que en su mayoría se encargan de desasociar / deserializar los argumentos y en realidad ejecuta la función / método remoto. Obviamente, los talones de los clientes se encuentran en el lado del cliente, mientras que los trozos del servidor (a menudo llamados esqueletos) se encuentran en el lado del servidor.
Escribir buenos talones genéricos y eficientes se convierte en todo un desafío cuando se trata de referencias a objetos. La mayoría de los marcos de objetos distribuidos como RMI y CORBA tratan con referencias de objetos distribuidos, pero eso es algo que la mayoría de los programadores evitan en entornos REST, por ejemplo. Por lo general, en entornos REST, los programadores de JavaScript realizan funciones de stub simples para encapsular las invocaciones de AJAX (la serialización de objetos es compatible con JSON.parse y JSON.stringify ). El proyecto Swagger Codegen proporciona un amplio soporte para generar automáticamente stubs REST en varios idiomas.
Por ejemplo, ¿qué significa en esta cita?
La integración con una API externa es casi una garantía en cualquier aplicación web moderna. Para probar de manera efectiva tal integración, debe anularla . Un buen apéndice debe ser fácil de crear y estar constantemente actualizado con las respuestas API actuales y actuales. En esta publicación, describiremos una estrategia de prueba usando stubs para una API externa.
Stub es una definición de función que tiene el nombre de la función correcta, el número correcto de parámetros y produce un resultado ficticio del tipo correcto.
Ayuda a escribir la prueba y sirve como una especie de andamiaje para que sea posible ejecutar los ejemplos incluso antes de que se complete el diseño de la función.
Términos de Layman, son datos ficticios (o datos falsos, datos de prueba, etc.) que puede usar para probar o desarrollar su código hasta que usted (o la otra parte) esté listo para presentar / recibir datos reales. Es el "Lorem Ipsum" de un programador.
¿La base de datos del empleado no está lista? Inventa uno simple con Jane Doe, John Doe ... etc. API no está lista? Inventa uno falso creando un archivo .json estático que contenga datos falsos.
Un stub , en este contexto, significa una implementación simulada.
Es decir, una implementación simple y falsa que se ajusta a la interfaz y se utilizará para las pruebas.
Un stub es un reemplazo controlable para una Dependencia Existente (o colaborador) en el sistema. Al usar un stub, puedes probar tu código sin tratar directamente con la dependencia.
Dependencia Externa - Dependencia Existente:
Es un objeto en su sistema que su código bajo prueba interactúa con y sobre el cual usted no tiene control. (Ejemplos comunes son sistemas de archivos, hilos, memoria, tiempo, etc.)
Por ejemplo, en el siguiente código:
public void Analyze(string filename)
{
if(filename.Length<8)
{
try
{
errorService.LogError("long file entered named:" + filename);
}
catch (Exception e)
{
mailService.SendEMail("[email protected]", "ErrorOnWebService", "someerror");
}
}
}
Desea probar el método mailService.SendEMail () , pero para hacerlo necesita simular una excepción en su método de prueba, por lo que solo necesita crear un objeto Fake Stub errorService para simular el resultado que desea, entonces su código de prueba será capaz de probar el método mailService.SendEMail () . Como ve, necesita simular un resultado que proviene de otra Dependencia que es un objeto de clase ErrorService (objeto Dependencia existente).