Stub (computación distribuida)

format_list_bulleted Contenido keyboard_arrow_down
ImprimirCitar

En la informática distribuida, un stub es un programa que actúa como reemplazo temporal de un servicio u objeto remoto. Permite que la aplicación cliente acceda a un servicio como si fuera local, mientras oculta los detalles de la comunicación de red subyacente. Esto puede simplificar el proceso de desarrollo, ya que la aplicación cliente no necesita ser consciente de las complejidades de la informática distribuida. En cambio, puede confiar en el stub para manejar la comunicación remota, al tiempo que proporciona una interfaz familiar con la que trabajar para el desarrollador.

Aplicación

El stub representa un objeto o servicio remoto en un sistema local. Actúa como un proxy para el servicio remoto y permite que el programa cliente realice llamadas a métodos en el objeto remoto como si fuera local. El proceso de generación de stubs implica la creación de un objeto proxy del lado del cliente que proporciona la misma interfaz que el servicio remoto, pero enruta las llamadas a métodos al objeto remoto real.

En la informática distribuida, un stub es un fragmento de código que convierte los parámetros que se pasan entre el cliente y el servidor durante una llamada a procedimiento remoto (RPC). El objetivo principal de una RPC es permitir que una computadora local (cliente) invoque procedimientos en una computadora remota (servidor). Dado que el cliente y el servidor tienen diferentes espacios de direcciones, los parámetros utilizados en una llamada a función deben convertirse. De lo contrario, los valores de los parámetros serían inutilizables porque los punteros a los parámetros en la memoria de una computadora harían referencia a datos diferentes en la otra computadora. Además, el cliente y el servidor pueden tener diferentes representaciones de datos, incluso para parámetros simples como números enteros (por ejemplo, big-endian versus little-endian). Los stubs manejan la conversión de parámetros, haciendo que una llamada a procedimiento remoto parezca una llamada a función local en la computadora remota.

Las bibliotecas stub son cruciales en la computación distribuida, ya que permiten realizar llamadas a procedimientos locales a objetos o servicios remotos. El stub o proxy del lado del cliente es responsable de convertir los parámetros utilizados en una llamada a una función y de deshacer la conversión de los resultados devueltos por el servidor después de ejecutar la función, un proceso conocido como marshalling. Las bibliotecas stub deben instalarse tanto en el cliente como en el servidor, y el stub del lado del servidor, o esqueleto del servidor, es responsable de deshacer la conversión de los parámetros pasados por el cliente y convertir los resultados después de ejecutar la función. En entornos de prueba virtuales, los stubs se utilizan para simular la computación distribuida, lo que permite una verificación más eficiente y efectiva de las actualizaciones de software en sistemas automotrices ricos en variantes.[4]

Pasos para escribir pruebas con problemas

Para escribir pruebas con stubs, siga estos pasos:

  1. Identificar los componentes o servicios externos que el componente que se está probando depende para funcionar correctamente.[2] o crear manualmente versiones de problemas de las dependencias que devuelven valores o respuestas predefinidos cuando se llama por el componente bajo prueba.
  2. Escribir casos de prueba para el componente, utilizando los problemas en lugar de las dependencias reales.[2]
  3. Establecer el entorno de prueba inicializando el componente bajo prueba y sus problemas.
  4. Ejecute las pruebas y analice los resultados. Si las pruebas fallan, revise el código y los problemas para determinar la causa del problema.[2]
  5. Refactor el código y los problemas necesarios para mejorar la calidad de las pruebas y el componente.[3]

Es fundamental utilizar stubs solo cuando sea necesario, ya que pueden introducir complejidad adicional y gastos de mantenimiento. Además, los stubs deben imitar con precisión el comportamiento de las dependencias reales para evitar introducir falsos positivos o negativos en las pruebas.[2]

Referencias

  1. ^ Coulouris, Dollimore, " Kindberg (2011). Sistemas distribuidos: Conceptos y Diseño. Pearson Education, Inc.{{cite book}}: CS1 maint: múltiples nombres: lista de autores (link)
  2. ^ H. Guissouma, A. Lauber, A. Mkadem, E. Sax (2019). Virtual Test Environment for Efficient Verification of Software Updates for Variant-Rich Automotive Systems. IEEE.{{cite book}}: CS1 maint: múltiples nombres: lista de autores (link)
  3. ^ Freeman, S., " Pryce, N. (2009). Software orientado por objetos crecientes, guiado por pruebas. Pearson Education, Inc.{{cite book}}: CS1 maint: múltiples nombres: lista de autores (link)
  4. ^ Meszaros, G. (2003). x Patrones de prueba de unidad: Código de prueba de refactorización. Pearson Education, Inc.
Más resultados...
Tamaño del texto:
undoredo
format_boldformat_italicformat_underlinedstrikethrough_ssuperscriptsubscriptlink
save