La semana del 8 al 12 de septiembre tuvieron lugar las “Jornadas Sistedes”, el punto de encuentro de referencia, a nivel estatal, de los investigadores en ingeniería del software. Como ya es costumbre desde hace varios años, algunos miembros del inLab FIB tuvimos la oportunidad de asistir y presentar algunas de nuestras líneas de investigación actuales en esta materia.
En este artículo, nos centraremos en una de ellas: el Declarative Domain Testing, un nuevo enfoque para implementar los tests de software, mejorando su calidad y reduciendo los costes.
Para explicarlo, supongamos que un cliente, con una vida social admirable, nos pide que le desarrollemos un sistema de software muy sencillo para registrar qué días ha sido invitado a cenar a casa de un amigo o familiar. En concreto, quiere registrar el día y la hora de cada cena, el lugar, la persona que la organiza y los asistentes a la misma (donde cada cena siempre tiene un mínimo de dos asistentes). Además, nuestro cliente nos advierte que es muy despistado y que en alguna ocasión ha aceptado dos invitaciones el mismo día, lo que le ha puesto más de una vez en un compromiso… Por eso, el cliente está muy interesado en que la aplicación lance un aviso si intenta aceptar dos invitaciones simultáneas.
Como buenos ingenieros de software que somos, aplicamos la filosofía TDD (Test-Driven Development) y nos decidimos a crear un test que nos obligue a implementar esta funcionalidad de lanzamiento de aviso. El caso es que, para crear el test, necesitamos que nuestro cliente tenga una cena ya registrada en el sistema (por ejemplo, el 25 de diciembre), pero para crear esta cena necesitamos tener registrada en el sistema a otra persona que la organice (por ejemplo, la madre de nuestro cliente), y esta cena necesitará un mínimo de dos asistentes, por lo que necesitaremos instanciar al menos a una segunda persona (por ejemplo, el padre de nuestro cliente)… además necesitaremos un lugar (por ejemplo, la casa de los padres del cliente) y ¡ahora nos falta otra cena! Y esta otra cena también requiere instanciar a dos personas más (por ejemplo, los suegros del cliente). Y estas dos personas no pueden ser las mismas que hemos usado antes, porque nadie puede estar en dos cenas el mismo día (ni es recomendable que tus padres sean también tus suegros).
En resumen, construir el estado previo de un test puede ser increíblemente tedioso, incluso con ejemplos de software tan sencillos como este que acabamos de describir (y ahora, imagínense que estamos desarrollando una aplicación real de calendario de visitas de un hospital que puede tener restricciones de no solapamiento temporal como la anterior, junto con restricciones mucho más complejas sobre tratamientos, enfermedades, alergias, visitas con especialistas, etc.). El resultado ya lo conocemos todos: cuando construir el test requiere más esfuerzo que implementar la funcionalidad, o bien nos mantenemos estoicamente fieles a construir los tests (para desesperación del responsable económico del proyecto, que ve multiplicarse los costes de cada nueva funcionalidad), o bien dejamos de implementar los tests (para desesperación de los desarrolladores futuros del proyecto, que ven un riesgo en la calidad y mantenibilidad de este).
Desde el inLab FIB, sin embargo, hacemos la siguiente observación: ¡lo único que necesitamos para hacer el test es un cliente con dos invitaciones a cenar el mismo día! Y esta descripción de lo que necesitamos ocupa, literalmente, 1, 2, 3… 10 palabras. ¿Cómo puede ser tan difícil para un desarrollador? En resumen, esta es la enésima representación de un fenómeno muy conocido: declarar en abstracto lo que queremos es mucho más rápido que implementar en concreto lo que necesitamos, porque la implementación concreta nos obliga a decidir detalles que no queremos (como la fecha concreta, las personas concretas, los lugares concretos, etc., de la cena). ¿No se puede automatizar un poco más esta parte?
En el congreso, planteamos la filosofía DDT (Declarative-Domain Testing), basada en declarar qué queremos en el test mediante un lenguaje de especificación, e integrar una IA de razonamiento simbólico que instancie los datos que satisfacen esta especificación (los detalles que nos resultan indiferentes, pero que deben elegirse de manera inteligente para cumplir con las necesidades del test). Además, en el congreso también presentamos la librería DArrenge4J, actualmente en desarrollo, que permite llevar esta filosofía a la práctica en proyectos Java con JUnit.
Si les interesa el tema, pueden consultar más información en un artículo más extenso publicado en CAiSE 2025, con Martí Juanola, José Francisco Crespo, un servidor y Ernest Teniente, o directamente, contactarnos 😉