Pruebas de integración y su aplicación Couchbase

Las pruebas de integración adecuadas requieren una configuración completa de su infraestructura. Y esto puede ser un poco difícil de poner en marcha a veces, sobre todo cuando se necesita para apoyar su lapop desarrollador, su nodo de CI, o cualquier otra máquina en la que necesita para ejecutar sus pruebas. Una buena solución para arreglar esto es utilizar contenedores como un tiempo de ejecución común. Docker funciona igual en todas las máquinas. Así que mientras esté instalado en tu portátil de desarrollador y en tu nodo CI, estás bien :) Así que una vez más te voy a mostrar cómo hacer esto usando Contenedores de prueba.

Qué queremos probar

Hay una gran aplicación de ejemplo para probar Couchbase con el Travel Sample. El backend Java se encuentra aquí https://github.com/couchbaselabs/try-cb-java/ y el frontend aquí https://github.com/couchbaselabs/try-cb-frontend/. Te permitirá entender varias características como N1QL, FTS o subdocumentos. Es un gran lugar para empezar a aprender Couchbase. Y aunque es un gran lugar para aprender, todavía no tenemos ninguna prueba de integración para ello. Así que empecé un nuevo proyecto para remediar eso. Está disponible en https://github.com/couchbaselabs/try-cb-integration-test. Sobre esto escribiré hoy.

Configuración de la prueba

Para probar el frontend voy a utilizar Selenium. Te permite básicamente especificar dónde quieres hacer click en una página, introducir keystokes y verificar el contenido de una página. Así que puedes decirle al controlador de selenio que cargue una página en una URL en particular, verificar que se carga correctamente, hacer clic en un enlace y verificar que la nueva página te lleva a donde querías. Eso es todo lo que vamos a hacer hoy en lo que a pruebas se refiere. Lo importante aquí es cómo configurar esto. Primero echa un vistazo a mi código de prueba:

Si estás familiarizado con Selenium, probablemente te duelan los ojos al mirar esos grandes y largos valores XPath. En la mayoría de las aplicaciones, esto será reemplazado por el id del elemento DOM que estás buscando. Ahora que tenemos esto fuera del camino, echa un vistazo a la primera línea: RemoteWebDriver driver = chrome.getWebDriver();

El controlador Selenium fue dado por un objeto chrome. Este objeto representa un Container ejecutando selenium. Esto es posible gracias a TestContainers y su integración con Selenium. Pero como es un contenedor, para acceder a algo más, o lo construyes en el contenedor o tienes que enlazar con otro contenedor. Que es por supuesto lo que se ha hecho. Para ejecutar la Muestra de Viaje necesitas tres cosas. Necesitas un Couchbase Server, un Travel Sample Backend y un Travel Sample Frontend, preferiblemente todos en su propio contenedor. Afortunadamente tenemos una imagen Docker para cada uno de ellos. Por favor, consulte el Léame del proyecto si quieres construirlos.

Para que todo esto funcione, necesitas iniciarlos en un orden particular. Primero inicia Couchabse porque lo necesita el Backend. Después arranca el backend porque lo necesita el frontend, después el frontend porque lo necesita la imagen Selenium que contiene selenium y un navegador. Así que tenemos que asegurarnos de que cada contenedor está iniciado y listo antes de lanzar el otro. Digo listo porque puede ser diferente de iniciado en algunos casos. Cuando inicias un contenedor Couchbase, tienes que configurarlo. En cuanto a la aplicación Spring Boot para el backend, tarda algún tiempo en estar arrancada y lista para aceptar conexiones. Afortunadamente TestContainers ha pensado en esto y proporciona algún mecanismo de espera interesante.

Empecemos con el Contenedor Couchbase:

Puedes ver que se puede configurar fácilmente con esta API fluida. Aquí estoy configurando esto para que tenga activados los servicios FTS, Index y Query, que la muestra de viajes esté precargada, con mi propio nombre de usuario y contraseña y con un bucket por defecto también.

Usualmente con TestContainers tendrías esto tiene un @ClassRule en tus pruebas. Lo que iniciaría el contenedor automáticamente. Pero arrancaría todo con una @ClassRule al mismo tiempo. Desafortunadamente no podemos hacer eso porque como explicamos antes, los contenedores necesitan estar listos antes de iniciar el siguiente. Así que podemos arreglárnoslas añadiendo un bloque de código estático. Todos se ejecutan en orden. Así que si iniciamos nuestro contenedor en un bloque de inicio, podemos asegurarnos de que están listos antes del siguiente bloque estático. La estrategia CouchbaseContainer Waiting hace sondeos sobre el estado de la API REST de Couchbase y se asegura de que el estado del nodo es saludable para considerarlo listo y dejar de esperar. Si quieres más detalles sobre CouchbaseContainer puedes mirar el código aquí y también en el anterior blog puestos sobre Couchbase y TestContainers.

El siguiente paso es iniciar el backend Java ya que Couchbase está listo:

Algunas cosas interesantes a tener en cuenta aquí. De nuevo la presencia de un bloque estático que inicia el contenedor por las mismas razones expuestas anteriormente. Puedes ver que estamos exponiendo el puerto 8080 aquí. No es necesario hacerlo con CouchbaseContainer ya que es una clase específica dedicada a la imagen por defecto de Couchbase. Como tal tiene una configuración por defecto para los puertos así como una estrategia de espera predefinida. Para el backend usamos un GenericContainer por lo que necesitamos especificarlo. La estrategia de espera esperará hasta obtener un 404 para la ruta configurada. Si responde algo entonces básicamente el servidor está arriba y Frontend puede usarlo. También verás que el parámetro Java que define la dirección de Couchbase es dado y el valor es obtenido de la instancia CouchbaseContainer.

La última información muy útil es la llamada al método withLinkToContainer. No forma parte de la API GenericContainer, no sé por qué. Tuve que extenderlo:

Todo lo que hace es asegurarse de que habrá un enlace Docker entre el CouchbaseContainer y el backemd. De esta forma te aseguras de que los contenedores pueden hablar entre ellos.

Ahora que Couchbase y el Backend están listos podemos empezar con el Frontend. Es una aplicación Angular2 dentro de la plataforma contenedor nginx por defecto. Necesita acceder al backend por lo que necesitamos añadir un enlace al contenedor anterior. Algo que necesitas asegurarte es poder cambiar la URL del servidor backend dinámicamente en tu app Angular. Esto se puede hacer fácilmente con Environments. Esta imagen de prueba ha sido construida con los entornos de prueba y como tal busca el hostname trycbBack, que es el nombre que se da en el método withLinkToContainer. Y de nuevo iniciamos el contenedor en un bloque estático.

Una vez que todos estos contenedores están funcionando podemos iniciar el contenedor Selenium. Este es parte del proyecto TestContainers y te da acceso a varias características. Puedes decidir si quieres usar Chrome o Firefox y si quieres que se grabe la prueba. En nuestro caso es un controlador de Chrome y la prueba será grabada y almacenada en el fodler de destino. También observarás que añadimos un enlace tanto al Frontend como al Backend. El Frontend se accede en el Chrome brower dentro del contenedor, y la app angular accederá al backend desde él. Así que tienes que asegurarte de que también es accesible desde el contenedor Selenium y que tu configuración CORS permitirá la comunicación.

Ahora ya tienes todo configurado y puedes ejecutar el test presentado al principio de este post. Espero que te haya sido útil y que ahora utilices TestContainers para realizar fácilmente pruebas de integración de aplicaciones basadas en Couchbase.