X
BLOG

Cómo simular defectos con la virtualización de servicios

Cómo simular defectos con la virtualización de servicios Tiempo de leer: 3 minutos

En mi última publicación de blog sobre la virtualización de servicios, hablé de las pruebas utilizando una respuesta virtual para simular el comportamiento de la aplicación que aún estaba evolucionando o aún no estaba disponible. Hoy me dirijo a la siguiente pregunta: ¿qué pasa si hay requisitos o condiciones adicionales que no se pueden crear con la aplicación normal porque el comportamiento del sistema backend requiere algunas configuraciones anormales?

La virtualización de servicios nos permite abordar este desafío no solo brindándonos acceso ilimitado a la tecnología y los sistemas backend, sino también permitiéndonos tomar el control de las respuestas proporcionadas por esos componentes. Por lo general, la virtualización de servicios se usa para simular el comportamiento de la ruta feliz de los componentes dependientes en un entorno, o para llenar un vacío cuando falta un componente, pero hay otro lado en este punto. Podríamos invertir ese flujo de trabajo y usar la virtualización de servicios para simular un comportamiento anormal de un componente existente.

Simulación de comportamiento anormal

¿Qué es la simulación de comportamiento anormal? De manera más simple, se refiere a proporcionar respuestas negativas de los servicios de una manera predecible para validar o protegerse contra el comportamiento específico de la aplicación. Para ilustrar este concepto, podríamos considerar una situación en la que un desarrollador quiere blindar su aplicación contra interrupciones del flujo ascendente. Esto suena como una tarea importante para todos los desarrolladores, pero de manera realista, hacerlo normalmente es imposible.

Imagine al desarrollador que crea una aplicación de carrito de compras que aprovecha PayPal y desea incorporar alguna funcionalidad que maneje una interrupción de PayPal. Quizás quieran asegurarse de que el usuario final no pierda su progreso si PayPal se desconecta repentinamente o envía una respuesta negativa. Probar esta condición sería un desafío en un entorno real. ¿Cómo haría esto un desarrollador sin virtualización? Imagínese una llamada telefónica a PayPal: "¿Podría hacer que el tiempo de espera de sus servidores se agote durante unas horas hoy?" No solo no será una conversación agradable, sino que incluso si, por si acaso, presentaran el comportamiento negativo, afectaría a todo el entorno de desarrollo. Cualquiera que quisiera probar contra la API de PayPal ese día sufriría.

Aquí es donde la virtualización de servicios es tan poderosa. Dado que el desarrollador tiene el control del servicio virtual, será fácil para ellos configurar este comportamiento anormal. Podrían crear una interfaz de PayPal virtual en su propio punto final privado haciendo referencia a la documentación WSDL o Swagger proporcionada por PayPal o cualquier contrato de servicio de terceros. Luego entrarían en el servicio virtual y lo establecerían en "Error interno del servidor 500. " Esto permitiría al desarrollador ver qué pasaría con su código en estas condiciones. Llevando esto un poco más lejos, podrían simular un "200 OK”Pero responda con JSON con formato incorrecto o incluso configure el servicio para que responda con un retraso considerable solo para ver qué sucede. Las posibilidades son infinitas.

Este tipo de pruebas anormales bajo demanda es invaluable. Permite a los desarrolladores manipular su código mientras controlan todo tipo de comportamiento de respuesta anormal. Esto acelera el proceso de validación y mejora el código de la aplicación en general. Pero ahí no se detiene. Hay áreas adicionales, generalmente impensadas, en las que la simulación de un comportamiento anormal del servicio puede ser un gran beneficio para las organizaciones de desarrollo, y esa es la idea de la virtualización de defectos.

Entonces, ¿qué es la virtualización de defectos?

Piense en la virtualización de defectos como una "repetición negativa". Lo que está haciendo es crear un entorno anormal para que una aplicación "viva". Piense en un muñeco de prueba de choque: no va a colocar un muñeco de prueba de choque en un automóvil que simplemente va a conducir por la carretera en condiciones normales. Lo más probable es que el entorno en el que se ha colocado ese muñeco esté especialmente configurado para proporcionarle un día bastante malo.

Esto es lo mismo en la virtualización de defectos. La simulación de condiciones negativas que podrían ocurrir externamente obligará a una aplicación a exponer algún tipo de comportamiento inesperado. Esto puede ser bastante poderoso porque puede usar ese entorno simulado para reproducir el comportamiento de los equipos de control de calidad o de desarrollo. El equipo podría tomar esta simulación y ver, de primera mano, cuál es el problema. Esto reproduciría el comportamiento negativo para ellos de manera consistente y en el proceso de arreglar la aplicación podrían "reproducir" el escenario en el entorno negativo, para asegurarse de que el nuevo código haya resuelto el problema.

En el video a continuación, mostraré cómo realizar pruebas contra condiciones anormales, bajo demanda. También voy a descubrir un defecto en mi aplicación y mostrar cómo a través de pruebas anormales puedo reproducir de manera confiable las condiciones que lo exponen. Haré esto dentro de la nueva libre Edición comunidad de Parasoft Virtualize.

Escrito por

Chris Colosimo

Como Gerente de Producto en Parasoft, Chris elabora estrategias para el desarrollo de productos de las soluciones de pruebas funcionales de Parasoft. Su experiencia en la aceleración de SDLC a través de la automatización lo ha llevado a implementaciones empresariales importantes, como Capital One y CareFirst.

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.

Prueba Parasoft