La semana del 8 al 12 de septiembre tuvieron lugar las \u201cJornadas Sistedes\u201d, el punto de encuentro de referencia, a nivel estatal, de los investigadores en ingenier\u00eda del software. Como ya es costumbre desde hace varios a\u00f1os, algunos miembros del inLab FIB tuvimos la oportunidad de asistir y presentar algunas de nuestras l\u00edneas de investigaci\u00f3n actuales en esta materia. <\/p>\n\n
En este art\u00edculo, 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.<\/p>\n\n
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\u00e9 d\u00edas ha sido invitado a cenar a casa de un amigo o familiar. En concreto, quiere registrar el d\u00eda 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\u00ednimo de dos asistentes). Adem\u00e1s, nuestro cliente nos advierte que es muy despistado y que en alguna ocasi\u00f3n ha aceptado dos invitaciones el mismo d\u00eda, lo que le ha puesto m\u00e1s de una vez en un compromiso\u2026 Por eso, el cliente est\u00e1 muy interesado en que la aplicaci\u00f3n lance un aviso si intenta aceptar dos invitaciones simult\u00e1neas. <\/p>\n\n
Como buenos ingenieros de software que somos, aplicamos la filosof\u00eda TDD (Test-Driven Development<\/em>) 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\u00e1 un m\u00ednimo de dos asistentes, por lo que necesitaremos instanciar al menos a una segunda persona (por ejemplo, el padre de nuestro cliente)\u2026 adem\u00e1s necesitaremos un lugar (por ejemplo, la casa de los padres del cliente) y \u00a1ahora nos falta otra cena! Y esta otra cena tambi\u00e9n requiere instanciar a dos personas m\u00e1s (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\u00eda (ni es recomendable que tus padres sean tambi\u00e9n tus suegros). <\/p>\n\n En resumen, construir el estado previo de un test puede ser incre\u00edblemente tedioso, incluso con ejemplos de software tan sencillos como este que acabamos de describir (y ahora, imag\u00ednense que estamos desarrollando una aplicaci\u00f3n real de calendario de visitas de un hospital que puede tener restricciones de no solapamiento temporal como la anterior, junto con restricciones mucho m\u00e1s complejas sobre tratamientos, enfermedades, alergias, visitas con especialistas, etc.). El resultado ya lo conocemos todos: cuando construir el test requiere m\u00e1s esfuerzo que implementar la funcionalidad, o bien nos mantenemos estoicamente fieles a construir los tests (para desesperaci\u00f3n del responsable econ\u00f3mico del proyecto, que ve multiplicarse los costes de cada nueva funcionalidad), o bien dejamos de implementar los tests (para desesperaci\u00f3n de los desarrolladores futuros del proyecto, que ven un riesgo en la calidad y mantenibilidad de este). <\/p>\n\n Desde el inLab FIB, sin embargo, hacemos la siguiente observaci\u00f3n: \u00a1lo \u00fanico que necesitamos para hacer el test es un cliente con dos invitaciones a cenar el mismo d\u00eda! Y esta descripci\u00f3n de lo que necesitamos ocupa, literalmente, 1, 2, 3\u2026 10 palabras. \u00bfC\u00f3mo puede ser tan dif\u00edcil para un desarrollador? En resumen, esta es la en\u00e9sima representaci\u00f3n de un fen\u00f3meno muy conocido: declarar en abstracto lo que queremos es mucho m\u00e1s r\u00e1pido que implementar en concreto lo que necesitamos, porque la implementaci\u00f3n concreta nos obliga a decidir detalles que no queremos (como la fecha concreta, las personas concretas, los lugares concretos, etc., de la cena). \u00bfNo se puede automatizar un poco m\u00e1s esta parte?<\/p>\n\n En el congreso, planteamos la filosof\u00eda DDT (Declarative-Domain Testing), basada en declarar qu\u00e9 queremos en el test mediante un lenguaje de especificaci\u00f3n, e integrar una IA de razonamiento simb\u00f3lico que instancie los datos que satisfacen esta especificaci\u00f3n (los detalles que nos resultan indiferentes, pero que deben elegirse de manera inteligente para cumplir con las necesidades del test). Adem\u00e1s, en el congreso tambi\u00e9n presentamos la librer\u00eda DArrenge4J, actualmente en desarrollo, que permite llevar esta filosof\u00eda a la pr\u00e1ctica en proyectos Java con JUnit. <\/p>\n\n