Como desarrolladores, con el paso de los años, nos hemos acostumbrado a disponer de un entorno de desarrollo que es una “replica” de un entorno productivo. A los entornos clásicos de integración, preproducción y producción hemos sumado el entorno “local” o desarrollo, es decir, aquel que cada desarrollador tiene en su propia máquina.

Las pruebas unitarias en las aplicaciones “tradicionales”
Con las aplicaciones que podemos llamar tradicionales, tenemos como mucho un interfaz web que accede a una base de datos relacional. Por supuesto, los entornos de desarrollo tienen facilidades para ejecutar dentro de sí un servidor de aplicaciones, que puede ser uno más sencillo como Tomcat o una versión de un servidor comercial como puede ser Websphere o Weblogic. Incluso disponemos de un servidor totalmente hecho en java  (por poner un ejemplo) destinado a hacer pruebas rápidas como es Jetty.

Con las bases de datos pasa algo parecido, podemos optar por tener una base de datos sencilla como es MySQL o una versión de “bolsillo” como puede ser Oracle. Incluso podemos tener una base de datos “simulada” en java y sistema de archivos como es el caso de “derbi”.
En cuanto a las dependencias, prácticamene no teníamos ninguna. Nuestra aplicación web accede únicamente a la base de datos y podemos probar en local toda su funcionalidad.

Las pruebas en las aplicaciones SOA
La cosa se complica con la orientación a servicios. Con SOA se componen servicios en base a otros servicios ya existentes. Evidentemente estos servicios ya existentes pueden no estar bajo nuestro control. Es decir, aunque pertenezcan a nuestra organización son propiedad de otro departamento, tienen otro equipo de desarrollo, con otro presupuesto, otras prioridades y otros calendarios.

¿Como hacemos para probar nuestro servicio que dependen de estos otros?
Parece claro que este es el papel del entorno de integración. Por eso precisamente se llama de esta manera. En este entorno todos los equipos pueden desplegar sus servicios de tal manera que es posible hacer una prueba de nuestra servicio o aplicación de frontal ya que tiene disponbible todas las dependencias que necesita.
¿y que pasa con el entorno local? evidentemente no se puede tener en local todos los servicios y recursos que se necesitan para hacer una prueba end-to-end de nuestras pantallas o servicios. Para ello tendríamos que tener una máquina parecida a las de producción y la gestión de estos despliegues sería inmanejable. Además hay que tener en cuenta que para que todos los servicios puedan ser ejecutados tendríamos que tener acceso a todas las bases de datos que se necesiten, a otros recursos como la NAS, un repositorio documental, etc. etc.

Soluciones
Una opción sería que desde nuestro servicio ejecutado en local pudiese invocar a otros servicios que estuviesen en otro entorno, el entorno de integración. Con esto tendríamos salvado el primer escollo. Sin embargo, si nuestro servicio usa una base de datos en local y el resto una base de datos en el entorno de integración a buen seguro empezarían a aparecer incoherencias en los datos que nos impedirían hacer una prueba completa. Además no estaríamos solucionado otro de los grandes problemas, la dependencia respecto a otros servicios y por ende a otros equipos de desarrollo con calendarios de implantación distintos. Tendríamos a buen seguro un interbloqueo entre los distintos equipos, cada uno esperando que el servicio del otro estuviese disponible.

Para evitar esto no queda otra opción que simular el resto de servicios con lo servicios mock o dummy. A primera vista parece contraproductivo ya que nos estamos cargando con más trabajo: la creación de los servicios dummy. Sin embargo las ventajas prácticas superan con creces este inconveniente:

  1. en primer lugar evitamos las dependencias con otros equipos de desarrollo. Únicamente necesitamos el WSDL para fabricar el servicio dummy. Además las herramientas nos facilitan enormemente esta tarea. En el mundo java existe la utilidad WSDL2Java que genera las clases que implementan el servicio.
  2. Con esto también evitamos posibles indisponibilidades del servicio al queremos invocar. El entorno de integración suele ser inestable por los continuos despliegues que hacen en él.
  3. Al tener los servicios dummy podemos implementar pruebas unitarias automatizables que podemos ejecutar una y otra vez sin depender de nadie.

Comparte esta entrada…
Share

Anuncios