¿Qué significa "stub" en programación?

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 efectivamente dicha integración, es necesario código auxiliar a cabo. Un buen código auxiliar debe ser fácil de crear y estar constantemente actualizado con las respuestas actuales de la API. En esta publicación, describiremos una estrategia de prueba usando stubs para una API externa.

Un stub es un reemplazo controlable para una dependencia existente (o colaborador) en el sistema. Al usar un stub, puede probar su código sin tener que lidiar con la dependencia directamente.

Dependencia externa - Dependencia existente:
es un objeto en su sistema con el que su código bajo prueba interactúa y sobre el cual usted no tiene control. (Los ejemplos comunes son sistemas de archivos, subprocesos, 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("admin@hotmail.com", "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, luego su código de prueba será capaz de probar el método mailService.SendEMail () . Como puede ver, debe simular un resultado que proviene de otra dependencia que es un objeto de clase ErrorService (objeto de dependencia existente).

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 va a utilizar para realizar pruebas.

En términos simples, 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 de empleados no está lista? Invente uno simple con Jane Doe, John Doe ... etc. ¿API no está lista? Invente uno falso creando un archivo .json estático que contenga datos falsos.

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 probar. Para evitar una mayor confusión, debemos definir qué es un código auxiliar.

En el contexto general, un stub es un fragmento de programa (normalmente una función o un objeto) que encapsula la complejidad de invocar otro programa (normalmente ubicado en otra máquina, VM o proceso, pero no siempre, también puede ser un 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 que se pasarán (y lo mismo con el resultado potencial), tal vez incluso lidiar con autenticación / seguridad, etc. Tenga en cuenta que en algunos contextos, los stubs también se denominan proxies (como proxies dinámicos en Java).

Un simulacro es un tipo de código auxiliar 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 usamos simulacros como programas locales (funciones u objetos) para reemplazar un programa remoto en el entorno de prueba. En cualquier caso, el simulacro puede simular el comportamiento real del programa reemplazado en un contexto restringido.

Los tipos más famosos de stubs son obviamente para programación distribuida, cuando se necesita invocar procedimientos remotos ( RPC ) u objetos remotos ( RMI , CORBA ). La mayoría de las bibliotecas / frameworks de programación distribuidos automatizan la generación de stubs 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 lenguaje para definir interfaces).

Por lo general, en RPC, RMI, CORBA, etc., se distinguen los stubs del lado del cliente , que en su mayoría se encargan de ordenar / serializar los argumentos y realizar la invocación remota, y los stubs del lado del servidor , que en su mayoría se encargan de desmarshaling / deserializar los argumentos y ejecutar la función / método remoto. Obviamente, los stubs de cliente se encuentran en el lado del cliente, mientras que los stubs de servidor (a menudo llamados esqueletos) se encuentran en el lado del servidor.

Escribir apéndices genéricos y eficaces se vuelve bastante complicado cuando se trata de referencias de 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 stub simples para encapsular las invocaciones de AJAX (la serialización de objetos es compatible con JSON.parsey JSON.stringify). El proyecto Swagger Codegen proporciona un amplio soporte para generar automáticamente stubs REST en varios idiomas.

Stub es una definición de función que tiene el nombre de función correcto, 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 andamio para hacer posible ejecutar los ejemplos incluso antes de que se complete el diseño de la función.

También tiene muy buenos marcos de prueba para crear tal código auxiliar. Uno de mis preferidos es Mockito. También hay EasyMock y otros ... Pero Mockito es genial, deberías leerlo - paquete muy elegante y poderoso

Esta frase es casi con certeza una analogía con una fase en la construcción de una casa: "cortar" la plomería. Durante la construcción, mientras las paredes aún están abiertas, se coloca la tubería en bruto. Esto es necesario para que la construcción continúe. Luego, cuando todo a su alrededor está lo suficientemente listo, uno regresa y agrega grifos e inodoros y el producto final real. (Consulte, por ejemplo, Cómo instalar un racor de plomería ).

Cuando "desconecta" una función en la programación, construye lo suficiente para trabajar con ella (para probar o escribir otro código). Luego, regresa más tarde y lo reemplaza con la implementación completa.

Stubs de RPC

• Básicamente, un stub del lado del cliente es un procedimiento que mira al cliente como si fuera un procedimiento de servidor invocable.
• Un stub del lado del servidor mira al servidor como si fuera un cliente que llama.
• El programa cliente cree que está llamando al servidor; de hecho, está llamando al código auxiliar del cliente.
• El programa servidor cree que lo llama el cliente; de hecho, lo llama el stub del servidor.
• Los stubs se envían mensajes entre sí para que suceda la RPC.

Fuente

"Eliminar una función significa que escribirá solo lo suficiente para mostrar que se llamó a la función, dejando los detalles para más adelante, cuando tenga más tiempo".

De: SAMS Teach yourself C ++, Jesse Liberty y Bradley Jones