La setmana del 8 al 12 de Setembre tingueren lloc les “Jornadas Sistedes”, el punt de trobada de referència, a nivell estatal, dels investigadors en enginyeria del software. Com ja és costum des de fa un bon grapat d’anys, uns quants membres de l’inLab FIB tinguérem l’oportunitat d’assistir-hi, i presentar algunes de les nostres línies d’investigació actuals en aquesta matèria.
En aquest article, ens centrarem en una d’elles: el Declarative Domain Testing, un nou enfocament per implementar els tests del software, millorant-ne la qualitat i reduint-ne els costs.
Per explicar-ho, suposem que un client, amb una vida social admirable, ens demana que li desenvolupem un sistema software, molt senzill, per registrar quins dies l’han convidat a sopar a casa d’un amic o familiar. En concret, vol registrar quin dia i hora és cada sopar, a quin lloc, quina és la persona que l’organitza, i quins assistents hi ha al sopar (on tot sopar sempre té un mínim de dos assistents). A més a més, el nostre client ens adverteix que és molt despistat, i que algun cop ha acceptat dues invitacions pel mateix dia, fet que l’ha posat més d’una vegada en un compromís… Per això, el client està molt interessat amb què l’aplicació llanci un avís si intenta acceptar dues invitacions simultànies.
Com a bons enginyers del software que som, apliquem la filosofia TDD (Test-Driven Development), i ens determinem a crear un test que ens obligui a implementar aquesta funcionalitat de llançament d’avís. El cas és que, per crear el test, necessitem que el nostre client tingui un sopar ja registrat al sistema (per exemple, pel 25 de Desembre), però per crear aquest sopar necessitem tenir registrat al sistema una altra persona perquè l’organitzi (per exemple, la mare del nostre client), però aquest sopar necessitarà un mínim de dos assistents, pel que necessitarem instanciar com a mínim una segona persona (per exemple, el pare del nostre client)…i necessitarem un lloc (per exemple la casa dels pares del client) i ara ens falta un altre sopar! I aquest altre sopar també requereix instanciar dues persones més (per exemple, els sogres del client!) I aquestes dues persones no poden ser les mateixes que hem fet servir abans perquè ningú no pot estar en dos sopars pel mateix dia (ni és aconsellable que els teus pares siguin també els teus sogres).
En resum, construir l’estat previ d’un test pot ser increïblement tediós, fins i tot amb exemples software tants senzills com aquest que acabem de descriure (i ara, imagineu-vos que estem desenvolupant una aplicació real de calendari de visites d’un hospital que pot tenir restriccions de no solapament temporal com l’anterior, juntament amb restriccions molt més complexes sobre tractaments, malalties, al·lèrgies, visites amb especialistes, etc). El resultat, ja el coneixem tots: quan construir el test requereix més esforç que implementar la funcionalitat, o bé ens mantenim estoicament fidels a construir els tests (per a desesperació del responsable econòmic del projecte, qui veu multiplicats el costs de cada nova funcionalitat), o bé deixem d’implementar els tests (per a desesperació dels desenvolupadors futurs del projecte, qui veuen risc en la qualitat i mantenibilitat d’aquest).
Desde l’inLab FIB però, fem la següent observació: l’únic que necessitem, per fer el test, és un client amb dues invitacions per sopar al mateix dia! I aquesta descripció del que necessitem ocupa, literalment, 1,2,3… 10 paraules! Com pot ser tant difícil per un desenvolupador? En resum, vet aquí la n-èssima representació d’un fenomen altament conegut: declarar en abstracte el que volem és molt més ràpid que implementar en concret el que necessitem, perquè la implementació concreta del que necessitem ens obliga a decidir detalls que no volem (com la data concreta, les persones concretes, els llocs concrets, etc. del sopar). I no es pot automatitzar una mica més aquesta part?
En el congrés, vam plantejar la filosofia DDT (Declarative-Domain Testing), basada en declarar què volem en el test, mitjançant un llenguatge d’especificació, i integrar una IA de raonament simbòlic que ens instancïi les dades que satisfan aquesta especificació (els detalls que ens resulten indiferents, però que s’han d’escollir de manera intel·ligent per satisfer les necessitats del test). A més a més, en el congrés també vam presentar la llibreria DArrenge4J, actualment en desenvolupament, que permet portar aquesta filosofia a la pràctica en projectes Java amb JUnit.
Si us interessa el tema, podeu consultar més informació en un article més extens publicat al CAiSE 2025, amb Martí Juanola, José Francisco Crespo, un servidor, i l’Ernest Teniente, o directament, contactar amb nosaltres 😉