The week of September 8th to 12th saw the \u201cJornadas Sistedes,\u201d 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. <\/p>\n\n
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.<\/p>\n\n
To explain it, let\u2019s 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\u2019s or relative\u2019s 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\u2026 Therefore, the client is very interested in the application raising an alert if he tries to accept two simultaneous invitations. <\/p>\n\n
As good software engineers, we apply the TDD (Test-Driven Development<\/em>) 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\u2019s mother), and this dinner will require at least two attendees, so we need to instantiate at least a second person (for example, the client\u2019s father)\u2026 plus we need a location (for example, the client\u2019s parents\u2019 house) and now we need another dinner! And this other dinner also requires instantiating two more people (for example, the client\u2019s 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). <\/p>\n\n 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\u2019s 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\u2019s quality and maintainability). <\/p>\n\n 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\u2026 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\u2019t care about (such as the specific date, the specific people, the specific locations, etc., of the dinner). Can\u2019t this part be automated a bit more?<\/p>\n\n 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\u2019s needs). Additionally, we also presented the DArrenge4J library, currently under development, which brings this philosophy into practice for Java projects using JUnit. <\/p>\n\n