The week of September 8th to 12th saw the “Jornadas Sistedes,” the national reference meeting point for software engineering researchers. As has been customary for several years, some members of inLab FIB had the opportunity to attend and present some of our current research lines in this field.
In this article, we will focus on one of them: Declarative Domain Testing, a new approach to implementing software tests that improves quality while reducing costs.
To explain it, let’s suppose a client, with an admirable social life, asks us to develop a very simple software system to record the days he has been invited to dinner at a friend’s or relative’s house. Specifically, he wants to record the date and time of each dinner, the location, the person organizing it, and the attendees (where each dinner always has a minimum of two attendees). Additionally, our client warns us that he is very forgetful and has, on occasion, accepted two invitations on the same day, which has put him in a bind more than once… Therefore, the client is very interested in the application raising an alert if he tries to accept two simultaneous invitations.
As good software engineers, we apply the TDD (Test-Driven Development) philosophy and decide to create a test that forces us to implement this alert feature. The issue is that, to create the test, we need our client to already have a dinner registered in the system (for example, on December 25th). But to create this dinner, we need another person registered in the system to organize it (for example, the client’s mother), and this dinner will require at least two attendees, so we need to instantiate at least a second person (for example, the client’s father)… plus we need a location (for example, the client’s parents’ house) and now we need another dinner! And this other dinner also requires instantiating two more people (for example, the client’s in-laws). These two people cannot be the same as those used before, because no one can be in two dinners on the same day (nor is it advisable for your parents to also be your in-laws).
In summary, building the precondition state of a test can be incredibly tedious, even with software examples as simple as the one just described (and now, imagine developing a real hospital visit scheduling application that may have temporal non-overlapping constraints like the above, along with much more complex constraints on treatments, illnesses, allergies, specialist visits, etc.). The outcome is well known: when building the test requires more effort than implementing the functionality, either we stoically remain faithful to writing the tests (to the despair of the project’s financial manager, who sees costs multiply with each new feature), or we skip writing tests (to the despair of future developers, who face risks to the project’s quality and maintainability).
From inLab FIB, however, we make the following observation: the only thing we need to create the test is a client with two dinner invitations on the same day! And this description of what we need takes, literally, 1, 2, 3… 10 words! How can this be so difficult for a developer? In short, this is yet another example of a well-known phenomenon: declaring abstractly what we want is much faster than concretely implementing what we need, because the concrete implementation forces us to decide on details we don’t care about (such as the specific date, the specific people, the specific locations, etc., of the dinner). Can’t this part be automated a bit more?
At the conference, we introduced the DDT (Declarative-Domain Testing) philosophy, based on declaring what we want in the test using a specification language, and integrating a symbolic reasoning AI that instantiates data satisfying this specification (details that are indifferent to us, but must be chosen intelligently to meet the test’s needs). Additionally, we also presented the DArrenge4J library, currently under development, which brings this philosophy into practice for Java projects using JUnit.
If you are interested in the topic, you can find more information in a more detailed article published at CAiSE 2025, with Martí Juanola, José Francisco Crespo, myself, and Ernest Teniente, or you can contact us directly 😉