Con este artículo ponemos en relieve la importancia que tiene realizar pruebas sobre cualquier nuevo elemento desarrollado en ABAP y también, sobre cualquier modificación que realicemos en código existente. El testeo unitario nos proporciona tanto el entorno de pruebas como las herramientas de análisis necesarias para poder verificar el correcto funcionamiento de una unidad de desarrollo.
Y es que está claro que a estas alturas, muy pocos dudarán de la necesidad de realizar pruebas integradas pero… ¿cómo vamos a ser capaces de encontrar errores en un sistema complejo si previamente no se han probado de manera suficiente todas las piezas que lo componen? El testeo unitario se centra en esto: pruebas sobre cualquier pequeña nueva pieza que se pretenda integrar en un sistema.
Vamos a empezar resaltando las ventajas e inconvenientes de los dos tipos de pruebas.
Tests Integrados
Ventajas:
- Se realizan en un entorno real
Desventajas:
- Configuración compleja del entorno
- Sólo se pueden realizar al finalizar el desarrollo
- Son lentos
- Análisis de errores complejo
- Son frágiles
- Necesitan un alto mantenimiento
Tests unitarios
Desventajas:
- Se realizan en un entorno simulado
Ventajas:
- Están aislados del entorno
- Se pueden realizar paralelamente al desarrollo
- Son rápidos
- Los errores son fáciles de analizar
- Son estables
- Necesitan poco mantenimiento
Como se puede ver, ambos tipos de pruebas son necesarios y complementarios. Y lo que es más importante, la aplicación de ambos nos permite aislar más fácilmente los errores y solucionarlos usando una cantidad de tiempo considerablemente menor.
Vamos a comentar más en detalle cada uno de los aspectos mencionados.
Los tests unitarios se realizan en un entorno simulado, es decir, no están influidos por las variables globales del entorno ni del sistema, entendiendo como tales a resultados de consultas a base de datos, todas las variables recogidas por la estructura SY (SY-DDATUM, SY-UNAME…), autorizaciones asociadas a roles, etc. Tampoco van a estar influidos por la relación con otros objetos, transacciones, programas o funciones externas a nuestro código. Esto no quiere decir que el objeto de los tests no los tenga en cuenta, sino que si algún tipo de estas situaciones tiene influencia en el objeto de análisis, pasarán a ser parámetros de configuración del entorno de test, sin necesidad de cambiar el código. Por lo tanto, el comportamiento del objeto en un entorno real no se va a conocer al 100%, pero si los tests están bien planteados, no supondrá mayor problema. Sabremos de antemano el comportamiento del objeto en cualquier situación. Esta desconexión del entorno nos permitiría, por ejemplo, hacer pruebas en un sistema en el que ciertas partes están rotas, en desarrollo o no funcionan de manera correcta. Toda relación externa está simulada y obedece a nuestra configuración. La filosofía es aislar el objeto a analizar para ver si funciona como se espera, sin interferencias del entorno. Y por ello, esta desventaja es a la vez una ventaja: aislamiento del entorno.
Como consecuencia, las pruebas se pueden hacer en paralelo al desarrollo, ya que no se necesita nada externo a nuestro objeto. Esto sólo va a tener consecuencias positivas, ya que los errores se detectan en una fase temprana y se corrigen. Además, el equipo de desarrollo se convierte a la vez en usuario durante las pruebas y se genera un código más limpio y legible, facilitando su uso e integración en el sistema.
Son rápidos porque durante las pruebas sólo se ejecuta el código que se quiere analizar y nada más. No es necesaria ni deseable la intervención de otros procesos y por eso las pruebas son muy ágiles.
Los errores son fáciles de analizar porque sólo hay que centrarse en el funcionamiento de un único elemento cuyo comportamiento es bastante predecible de antemano. Si la respuesta no es la esperada, las herramientas de análisis nos dirán el valor/es que se ha/n obtenido, el que se esperaba y todos los pasos que ha dado la ejecución para llegar e ese resultado.
Son estables porque están eliminadas todas las interferencias externas. Si una batería de tests tiene un resultado positivo, volverá a tenerlo en el futuro, siempre que no se cambie el código. Y si algún cambio introduce errores, tendremos información al instante. Esto supone una gran diferencia con los test integrados.
Necesitan poco mantenimiento. Sólo necesitan una inversión extra en tiempo durante la fase de desarrollo, ya que hay que diseñarlos y programarlos en paralelo. Pero una vez terminados, no es necesario volver a revisarlos, a no ser que se dote al objeto de nuevas funcionalidades. Además, existen técnicas de desarrollo (el desarrollo orientado a testeo o test driven development) que facilitan la labor y no son complicadas de asumir. El tiempo extra invertido se ve notablemente recompensado durante fases posteriores del proyecto, ya que se va a partir siempre de un código revisado, probado y robusto.
Por ahora esto es todo. Esperamos haber despertado vuestra curiosidad e interés. Los próximos artículos relacionados con el tema serán más técnicos y enfocados a desarrolladores ABAP. Pero creemos que hay que insistir y poner de relevancia este tema sin demasiados tecnicismos para concienciar a clientes y responsables de proyectos que es mejor y más deseable invertir tiempo en calidad que en corrección de errores. El debugging no suele ser simple y siempre es más costoso que el partir de una base de desarrollo firme y sólida.
el proceso:
