SERVICE VIRTUALIZATION… ¿es necesario?
Hace seis años, cuando arranqué trabajando como consultor con una solución de Virtualización de Servicios (Service Virtualization/SV), no era ninguna sorpresa que a todo cliente que iba, desconocía este tipo de solución y sus beneficios. Lo primero que imaginaban era a SV como alguna especie de competencia a VMWare o VirtualBox. Por supuesto era entendible, ya que eran muy reciente los conceptos de DevOps y Continuous Delivery. Mi trabajo consistía en explicarles de que se trataba, los beneficios y mostrarles la tecnología.
Al día de hoy, para muchos clientes con los que hablo, sigue siendo algo desconocido, o lo asocian con algún producto de una marca en particular. Me gustaría explicar el concepto, como encaja SV dentro del contexto de Entrega Continua, los casos en los que se justifica una solución de este tipo, y las diferencias con conceptos como mocks/stubs.
Entrega de Valor en cada despliegue
En Continuous Delivery se apunta a agilizar la llegada a producción de un cambio (o nueva funcionalidad) automatizando lo máximo posible a través de todo el ciclo de vida, aumentando la frecuencia de despliegues y reduciendo los riesgos a errores en el despliegue. Con esto último se busca obtener de manera más rápida feedback del usuario y entender el valor que se está entregando en cada despliegue. La implementación de Continuous Delivery permite que los sponsors del Negocio en cualquier momento puedan pedir un despliegue a Producción, y que este sea rápido y sin riesgo para los integrantes del equipo (devs, testers, operaciones, etc).
El Delivery Continuo se logra integrando de manera continua el desarrollo de los devs, ejecutando pruebas automatizadas para detectar problemas lo más pronto posible (shift-left) y desplegando los componentes en entornos similares a los productivos para realizar las validaciones de calidad suficientes y asegurarse que todo funcione correctamente en producción.
Si no se realizan estas pruebas, lo que estaríamos haciendo con el delivery continuo es hacer llegar más rápido los defectos a producción. Y como ya vimos el objetivo de CD es todo lo contrario, agregar valor en cada despliegue.
Este aseguramiento de la calidad en todas las etapas del ciclo de vida se la llama Continuous Testing y pregona que el testing NO es una fase que ocurre posterior al desarrollo y anterior al Despliegue y Mantenimiento, por el contrario, ocurre en todas las etapas, desde el diseño de los requerimientos hasta el despliegue en producción.
Ahora que estamos de acuerdo en que las pruebas son extremadamente necesarias, podemos hablar sobre los principales retos a la hora de realizar las pruebas.
Restricciones
Cuando hablo de retos, me refiero a las restricciones o limitaciones que nos hacen más dificultosa la tarea de probar nuestras desarrollos. Estas restricciones están fuera del alcance del desarrollador o tester, y son las responsables del retraso de los proyectos de software asi como también de la baja calidad de los mismos (ya que evitamos probar si va a ser complicado). Y cuando digo fuera del alcance me refiero dependencias que no forman parte del System Under Test (SUT) pero que son necesarias para realizar una prueba de calidad.
Ejemplos de estas restricciones pueden ser los Sistemas no disponibles, muchas veces debemos esperar a ventanas de tiempo para realizar las pruebas, Es muy común que algunos sistemas los habiliten solo un par de horas semanales para las pruebas (ej. Mainframe).
Entornos no escalables que por razones obvias distan de tener el rendimiento productivo y ademas se comparten con el resto de los equipos (se disponibiliza solo un entorno para las pruebas), forzando a que las pruebas fallen y no necesariamente porque nuestro software tenga algún defecto.
Otra razón de tener pocos entornos de prueba son los costos de infraestructura o de licenciamiento (SAP por ejemplo). También está el caso en el que se requiere simular ciertos escenarios para probar como lo maneja nuestro SUT y que son muy difíciles de reproducir (simular un timeout, códigos de error como respuesta, etc).
Existen casos donde los entornos de prueba tienen un costo, suele pasar con las APIs disponibilizadas por terceros donde tienen un costo superando un limite de consultas realizadas, o donde sufren penalidades de acceso si se supera algún limite establecido. Obviamente no podemos sacrificar calidad por el costo de las pruebas.
Nuestro SUT podría tener una dependencia que está siendo desarrollada en paralelo y que para poder probar ambas piezas se debería esperar a la finalización del desarrollo de ambas, haciendo que las pruebas se retrasen al fin de la Sprint y trabajar en la integración hasta último momento.
Y como último ejemplo, está la restricción de los datos de prueba, en este caso no hablamos de los datos que son parte del alcance del SUT (donde tenemos acceso y control de la base), me refiero a los datos que pertenecen a la dependencia y que no tenemos acceso a la misma. Una posible solución que he visto es la de proveer una API para poder dar de alta datos de prueba en las bases de la dependencia, si bien puede ayudar con la gestión de las pruebas (sumando complejidad), sigue siendo un riesgo la Volatilidad de los mismos (datos quemados), debido a que no se controla el uso de los mismo por otras pruebas y la tarea de reproducir de escenarios se hace casi imposible.
Que es la Virtualización de Servicios
La Virtualización de Servicios es una práctica que permite simular el comportamiento, los datos y el rendimiento de las dependencias del SUT sin ninguna restricción. Con la flexibilidad suficiente como para poder simular todos los escenarios necesarios para tener buena cobertura y reproducir las pruebas en procesos de integración continua.
Un Servicio Virtual no se limita solamente a servicios web (WS y Rest), podría ser cualquier dependencia que responda un mensaje ante una solicitud del SUT (http, jms, socket tcp, etc).
Service Virtualization provee independencia al realizar las pruebas, permitiendo las pruebas unitarias, de regresión e integración con anterioridad en el ciclo, haciendo posible el “shift-left”.
¿Stubs y Mocks?
Muchos piensan erróneamente que Service Virtualization reemplaza los Mocks y Stubs, y en realidad Service Virtualization es parte de la categoría de “test doubles”, en la cual también están los Mocks y los Stubs y según la necesidad va a depender la elección de la solución.
Los Stubs suelen ser pequeñas implementaciones de alguna interface que siempre devuelven resultados hardcodeados y que están totalmente acoplados a la prueba en cuestión (suelen ser test unitarios). Generalmente un Stub se crea en el entorno del desarrollador para realizar alguna prueba en el momento, pero es algo que no suele subirse al repositorio de código, solo es de uso personal. Algunas librerías suelen referirse a los Stubs cuando no es necesaria la verificación del llamado.
Los Mocks al igual que los Stubs, son implementaciones de interfaces, pero los mocks eligen la respuesta ante ciertos criterios predefinidos (parameter matching). Generalmente son creados con Frameworks como Mockito, Jmock, EasyMock, etc. Suelen ser creados por los developers y están destinados a complementar los Test Suites, simulando respuestas de clases y métodos. Son de gran soporte para la automatización de pruebas unitarias. Los mocks suelen verificar el estado del mismo, pudiendo validar el orden y cantidad de de llamados.
Simulando Servicios
Los Servicios Virtuales(SV) son llamados de manera remota, simulando la funcionalidad de una dependencia fuera del SUT. Las soluciones de SV facilitan la creación de los mismos a través de la captura del trafico entre el componente que realiza la solicitud y la respuesta de la dependencia. Durante esa captura, se modela el SV obteniendo los datos de los mensajes, tiempos y comportamiento y se crea un servicio para poder ser desplegado en un entornos de servicios virtuales. Esta opción de creación agiliza mucho las pruebas, pero no es la única opción, también se pude crear a partir de interfaces, definición de APIs (wsdls, swagger, raml, etc), pares de Request/Response, etc. Los SVs facilitan la reutilización de artefactos compartiendo a los equipos de desarrollo y testing los servicios que cada uno puede desplegar en sus propios entornos. Pueden simular no solamente respuestas según matchings de solicitudes, además permite simular características no funcionales como tiempos de respuesta, conexiones lentas, fallos de protocolo, etc. Algunas de las soluciones de SV suelen proveer una configuración dinámica, de manera que ante algún criterio en la solicitud pueda responder con una respuesta virtual o que en forma dinámica responda la dependencia real, todo esto en runtime.
Las plataformas de SV proveen APIs para poder integrar los deploys/undeploys de servicios, o cambios en la configuración para poder integrarlos con los procesos de Integración Continua o Pruebas de Performance.
Beneficios clave
- Desarrollo y pruebas en paralelo, permite que diversos equipos de desarrollo y prueba trabajen en paralelo, eliminando obstáculos y acelerando el time to market.
- Reducción de los requisitos de infraestructura, elimina la demanda de entornos creados para las pruebas y sus dependencias.
- Shift-Left, comenzar con las pruebas desde el inicio del ciclo de vida del software, reduciendo la complejidad del rework y los costos.
- Eliminación de los costos de servicios de terceros, evitar los costos de servicios de terceros simulándolos.
