Test Driven Development with PHP, PHPUnit and Symfony Framework - A Practical Case Study for a Scheduling System

1. Introduction

When an organization is dealing with a large number of redundant, obsolete, and trivial (ROT) data, the productivity and general output of that organization suffer a blow. The impact of ROT data can be easily addressed if proper planning and solutions are put in place.

According to the Veritas Global Databerg Report, 33% of data is ROT, yet many organizations hold on to this data for very long periods. Of course, a fear of the delete key is understandable, since the accidental removal of valuable data could have serious financial and legal repercussions. However, holding on to redundant, obsolete, or trivial data is not a trivial problem either (Robinson, 2023).

Many systems to patients' schedule have high complexity in engineering structure because of the process to open a new agenda to a doctor. These systems need to process each agenda with start and end periods and create a new row in the database with a unique hour. This process needs a long time to create all scheduled hours for each doctor in a period (normally, this process is ruined every month) in a medical clinic. Only after this process is done, we can execute the schedule of a patient with a doctor in a clinic. In this system, it was observed that many hours are never scheduled to a patient, this can be named like ROT (Redundant, Obsolete, and Trivial) data created, how observed by Gaidargi (2022).

The process described above is a waste because each medical specialty consult can have a different duration, adding more complexity that can impact on each agenda creation, demanding more time and storage space.

In this project, we intend to create a solution to avoid or minimize problems according to the ROT guidelines for a classic clinical scheduling system using computational systems. This proposal is to define a case study environment to validate in a practical way the application of a software development methodology oriented to the application of tests throughout the development.

2. Objective and Methodology

Web systems have become popular to enable new businesses, increasingly elaborate, with more complex and difficult-to-test rules.

This paper describes how I implemented a prototype to create agenda in a clinic with many doctors, this prototype show available hours that a patient can schedule a consult based only on the agenda config (with date and hour) and all schedules reserved, this is sufficient to calculate all free hours that the user can schedule the new patient to a doctor.

With TDD (Test-Driven Development), I will guarantee that new implementations, changes, or refractories do not break any rule, in different systems parts. And over time, all validations are executed again and all roles are retested, granting high quality.

3. Development

The case study for this project is built from the analysis of a real application environment, which will be used in this project as a research laboratory, providing information on requirements, problems, and practical space for validation tests, allowing a context very close to the reality, further enriching the results obtained. Negotiations, context problems, and the list of functionalities are based on empirical observation techniques, meetings, technical interviews, application of questionnaires, and immersion sessions.

3.1. Functional Specification

The prototype's operations comprise the functionalities that allow a medical professional or a receptionist to register patients, register doctors, open appointment books for a doctor, schedule a patient's appointment with a doctor, and cancel an appointment. All development will be done by applying the TDD (Test Driven Development) methodology, where the tests will be done before the code, thinking about different situations in which the software must perform the correct scheduling.

In this way, after the practical analysis activities for understanding the domain, understanding the problem, and identifying the basic functional requirements for the system, a minimal project was carried out to start the work. Functionally, the system would be based on a minimalist pattern to start development activities to allow a true TDD application laboratory in a volatile environment with intense evolution and susceptible to changes that would still be, purposefully, being elucidated in development time.

The structure of the system would be based on three well-divided modules, as can be seen in Figures 1 and 2, below:

• Administrative Maintenance Module,
• Maintenance Service Module and
• Schedule Management Module.

And for the operation of these three major modules, the system would allow two users, also well-defined:

• Administrative users - represented by the clinic itself; and that
• Clinic Staff - the counter-type staff

The use case diagram below (Figure 1 and Figure 2) demonstrates how the system's actors interact with the system to perform the actions defined in the purpose of this prototype. Figure 1 presents the operations available to the ADM maintenance module of the system.

According to the diagram (Figure 1), it is possible to identify the main functionalities of the system for employee actors (persona). Between them:

• Client's CRUD
• CRUD to Clinics
• CRUD to Employee

Figure 2 presents the operations available to the service maintenance and management modules of the system.

According to the diagram (Figure 1), it is possible to identify the main functionalities of the system for clinic user actors (persona). Between them:

From the service maintenance module:

• CRUD Specialist Doctors
• CRUD to Clinical Patient
• CRUD to Calendar

From the appointments management module:

• Schedule Appointment
• Appointment Service Management

The business entities are the related entities that together define a story for an appointment: CLINICA, MEDICO, AGENDA_DATA, CLIENTE, and PACIENTE. The management entities are concentrated around entities of the AGENDA type: AGENDA, AGENDA_CONFIG, AGENDA_DATA and AGENDA_STATUS. The USER entity is responsible for managing the system operation user.

Figure 3 shows the model designed for the project. This image is a class diagram that demonstrates the data model and the entities that will be used, along with the relationships for the system.

According to the analysis and modeling presented (Figure 3), we have user control, business, and key process entities:

1. User Control Data

• USER - System users. They are clinic employees with operating privileges, of the administrative assistance type.

2. Business Model Data

• CLINICA - It is the entity that allows the generalization of the system, so that a single installation can allow multiple controls, for example, as if each clinic were a profile or even several branches of the same network of clinical operations.
• MEDICO - This is a passive entity in the system (current version). This is the doctor who will be key to defining a service. Each specialist professional passes availability to the system operator (user) who is in charge of configuring each doctor's schedule and playing in the system.
• CLIENTE - This is the client of the clinic. It is this entity that is mandatory to initiate a scheduling process. The client may be scheduling an appointment for himself, in this case, he will be the patient himself, or for another patient.
• PACIENTE - Is the object of care. While the awareness is the basis for scheduling, the patient is the mandatory basis for care.

3. Key Process Model Data

• AGENDA - It is the definition (structure) of an agenda in the system. Basically, it is a logical metamodel of what a schedule is and how it should be handled in the system.
• AGENDA_CONFIG - Information that, when associated with an agenda structure, defines a specialist's calendar. A mandatory item for this entity is the relationship with the professional.
• AGENDA_DATA - It is the entity that concentrates the notes. For each appointment, it is necessary to have an agenda, a professional, and a patient (whether or not they are at the same time a client, at least.
• AGENDA_STA_STATUS - This is the entity that makes managing the status of an agenda_data more flexible. The management process is registered in this entity and at the same time controlled by a state machine process (design pattern).

3.2. Technical Specification

To replicate a web environment with multiple servers, Docker (https://www.docker.com/) will be used, with three containers to host the application, a container with Nginx (https://www.nginx.com/), a container with MariaDb (https://mariadb.org/) and a container to run the PHP (https://www.php.net/) application, according to Figure 4.

The development environment uses Docker to simulate an environment with distributed servers, including an Nginx (2023) server (a server to handle the HTTP protocol, receive a request and executing the PHP application), a PHP server and a server for the MariaDb (2023) database.

PHPUnit (PHP, 2023) allows the unit tests developed during the prototype implementation to be executed. The development cycle using TDD consists of writing the tests before the implementation, this creates a development flow where we create the test, it will fail before we have the implementation, and it will pass after deployment, but each time we do this cycle, we run all the tests and make sure the new deployment doesn't break what's already been created.

Symfony (2023) provides a basis for building the prototype, supporting concepts used in modern web systems, I will use the routes that allow the user to access the different URLs using the HTTP protocol (with a browser), the twig HTML templates, the ORM (Object Relational Mapper) Doctrine that allows working with a database abstraction that provides an easy way to define database tables and the relationships between them using entity classes, migrations created from defining entity classes (or templates from the MVC - Model View and Controller) and system permissions on routes to ensure a user has the correct credential to access a given page.

This image (Figure 4) presents the main technologies from their modules and their dependency interactions. In this image, it is also possible to identify that a partially independent context is set up to carry out the tests, mainly the unit tests that make up the inputs for the evolution of the TDD process.

It is important to point out that, although planned, in this version, it was not necessary to prepare the exclusive database instance for testing; the related tests in the project were unit tests typically of functional definition and business rules. The more technical tests were ignored regarding unit executions as a priority in this research.

4. Results

The obtained system can be accessed directly through the Github repository through the repository profile, which is publicly available (Cardenas, 2023.a). From this system, it is possible to assemble, in a very simple way, its implementation and execution due to the mechanisms of deployment based on containers (Cardenas, 2023.b).

Analogously, the body of Unit tests is also publicly distributed and can be easily identified in the same project, according to the packages corresponding to the test benchmarks.

With the use of Docker-compose in the Docker-PHP project (Cardenas, 2023.b), it was simple and easy to set up a local and secure environment, making it necessary only to configure the Symfony Framework with the database connection information, once configured, it is only necessary to access the PHP container to execute the command that executes the migrations and creates the database tables automatically and creates an ADMIN user after that the application can already be used.

The prototype available in the repository and distributed deployment, (Cardenas, 2023.a), has an ADMIN user, who manages clients and their clinics. It also registers users for the client, who is responsible for managing doctors, patients, schedules, and scheduling a patient for a doctor.

The schedules are configured based on the start and end day, the start and end time, and the duration of each query. This allows the creation of several schedules for the same period, but it cannot have overlapping times in different schedules.

To ensure that there is no ROT data on the appointments, a new row will only be generated in the database when a new appointment is made, for a day, time, and a patient, the algorithm that calculates the available appointments for a day must receive all the scheduled times of the selected day and schedule and return the available times for the user who is making the appointment to choose.

From this section on, an example of the prototype is shown, from a functional point of view. Figure 5 shows one of the possibilities for viewing the main screen of the system. It is possible to see the main user screen of the system (user), which would be the clinic employee. This user can manage doctors, patients, and appointments. It is because of this privilege, control of schedules, that this user is considered the main operating user of the system.

Also in this image (Figure 5), we can see a list of specialist doctors in the system, exemplifying one of the ways of accessing the management of appointments. It is from this list of expert professionals that the user can: remove, edit or control their appointment schedules.

Figure 6 demonstrates the process of registering a new professional in the system. A differential point in this creation process is the definition of a color, from a color palette, which should be used in the display of this professional's agenda.

It is a filling that makes the system user's activity difficult during the registration of doctors, but which has the objective of visually facilitating the identification of each professional when they are presented in the clinic's general agenda.

Since the number of times a doctor is registered in the system is much smaller than the number of times the calendars are displayed, the use of this component in filling in a new specialist is easily justified. It is even possible for the next versions of the system to define colors not yet used by default, as a preset.

As an example of agenda and appointment manipulation, the figures 7, 8 and 9 make a flow of demonstration by the user of the system by the clinic (employee). In these examples, the user is operating two main functionalities of the system:

1. creating and configuring an agenda to a doctor (Figure 6), which refers to the availability of specialist doctors;
2. viewing the calendar (Figure 7);
3. setting an appointment of a new patient request (Figure 8), and finally
4. obtaining the consolidated information of consultations in the general clinic (Figure 9).

All of them are carried out by the employee, who plays the role of interaction between a patient at the clinic and the system while the public and online access module is not available in the prototype app.

This image (Figure 7) presents the exclusive operations of ADMIN user manipulation bar. From these examples, it is also possible to identify the concern with the usability of the system, taking into account both the standardized and clean aesthetics and the ease of operation on behalf of the user. Such characteristics were facilitated by resources available directly in the PHP framework used in the project, which accelerates, above all, also the development of interface components in the system presentation layer, front-end.

In Figure 8, it is possible to identify the manipulation of a calendar for the clinic. This calendar brings, easily, the presentation of the agenda of each specialist professional of the clinic, identified by colors that distinguish each doctor. On the left side, this screen allows manipulation by the professional alone, and immediately below, the selection of a patient from the clinic so that, from there, further detailing the search filter.

In the upper bar, just above the calendar, it is possible to notice, by default, the navigation bar of the calendar, which takes place at the monthly level.

Figure 9 presents another step of scheduling manipulation of the prototype. This image shows the scheduled resume and the modal to include new activities. In this step, the user, of the employee type, selects a schedule from a professional, and fills in the information necessary to book the service (an appointment), that is, technically defining a relationship between three basic entities of the system: a doctor specialist, the patient and a time (date and time).

The time (AGENDA_DATA) for scheduling is defined from a modal screen, to facilitate the handling of the system by the employee. One of the facilities for filling in is due to pre-filled data and default data, that is, professional and date information.

This functionality (define an appointment) contains the main business rules for the system. It is in this functional module that most of the unit tests that were built for the system are concentrated. Since the main objective of this work was to analyze the impacts of TDD on the development of the prototype, it was at this point, "scheduling an appointment", that the main observations and research validations were concentrated.

This screen (Figure 10) also contemplates an extreme difficulty, in comparison with the system, in terms of GUI (Graphical User Interface) interface components; however, likewise, it was supported by framework resources that facilitate the construction of this type of module, thus allowing the business rules applied to the presentation layer to be elucidated, improved, or even corrected based on understandings arising from TDD evolution throughout the construction of the system.

After carrying out these basic steps that make up the process of handling an appointment, the system allows a compressed view of the information about the aged services, in general, consolidated, however exploring some usability definitions promoting ease of use; such as persistence in the use of colors, grouping, tables and navigation bars with daily flow.

To facilitate the manipulation of this page, the system allows visual reconfiguration of this report page. The user, if necessary, can redo the presentation of the data by modifying the search filters, the patient, or the physician.

For the current version of the prototype, the system still does not allow modifying the visualization of this report (figure 10) by period. That is, the current system does not allow the presentation of notes by month or week, for example.

5. Validation Process

The TDD (2023) was applied to ensure that different circumstances have the correct behavior on the algorithm that calculates the available times for a schedule and a date: "Even if a specialist doctor has more than one schedule for the day, with different configurations the duration of each query".

The tests cover two main points of the system:

• validation for the creation of a schedule for a doctor (where the rule is guaranteed that the schedules of two schedules cannot overlap) and
• the service that calculates the available times for a date in an agenda (the method that receives existing agendas and appointments to calculate the vacant times), being used to present the available times in an agenda on a certain date that the user selects.

As the tests ensured that the main flow and some other processes were always working (Figure 11), it was possible to focus on other flows that had not been explored until then, when testing, I found that these flows had behaviors that did not agree with the operation of the system. One of these problems was the creation of two schedules for the same period, wherein the first version it was not allowed, but when doing the manual tests this need was identified, taking into account the times and not just the date, now it is allowed to create more than a schedule for a doctor, as long as you don't have conflicting schedules (same schedule available in two schedules).

As unexpected behavior was discovered in the manual testing process, unit tests were implemented to ensure that this rule remains over time, even through refactoring and code changes.

3.5. Baby Steps Validation

The "baby steps" is an important part of the TDD process, and provide a safe environment to override and think through business rules. During the development of the rule that validates the creation of an agenda, the first step was ensuring that a date not be created for two agendas from one doctor.

In the next moment in the process, it started to insert hour on this validation, the result was my validating code broke, and at this moment, I not saw the root cause, I dispense many hours to understand why my unit tests broke on a consolidated tests.

The test that was broken, is about the two agendas with equal date start and end dates, this test needed to be removed because the adding hours on the solution, two agendas can exist with a same date range, but the hours can’t have intersections, and the next tests that I create have all hour validations, only others words, the rule changed when I started to work with hours.

The first test with an hour starts a test suite with more complex scenarios, which is guaranteed with each test like below (Code 1).

Code 1. A "baby steps" test function testPrimeiraAgendaComHorario

// TestFirstAgendaWithHour
public function testPrimeiraAgendaComHorario()
{
    $agenda = new Agenda();
    $agenda->setDataInicioAtendimento(new DateTime('2018-10-01'));
    $agenda->setDataFimAtendimento(new DateTime('2018-10-30'));
    $agenda->setHorarioInicioAtendimento(new DateTime('09:00'));
    $agenda->setHorarioFimAtendimento(new DateTime('12:00'));

    $resultado = $this->agendaValidator->validaDataDisponivel($agenda,[]);

    $this->assertTrue($resultado);

    return [$agenda];        
}

Additional scenarios were built to require more complex implementations, and for all the test cases I wrote with just a date, I replicate and add possibilities of hours.

After test accomplishment, all the test cases on schedule creation, my test suite had 18 tests just to validate the rules on schedule creation using dates and times to ensure a doctor has more than one schedule for a period without one-hour intersection.

Conclusion

The result achieved is an application using the Symfony framework, which provides a quick way to create the tables in the database through the migration patterns created during the prototype implementation, with tests that can be executed in a development cycle to guarantee that the functionalities already created in the course of this work do not undergo rule changes, these tests can and should be used in an automation environment where before each deploy is executed.

From an analytical point of view, development, in practice, is slower at the beginning, but with the assurance that new implementations or code refactoring bring greater quality to each development cycle as it cannot break existing tests. If that happens, developers can confirm with other stakeholders whether the change really should modify an already implemented rule. A real advantage, considering the implementation process based on TDD tracking, is the security for modifications, reconsideration, or new insertions still in development time that must be considered.

Source Code

The entire project is available in a public repository on GitHub. The structure of the project, as can be seen in Figure 12, is defined according to the standard frameworks used as support to accelerate the development, assembly and deployment of the system.

The project has always been guided by good development practices and design standards. All business entities followed guidelines and practices on object-oriented fundamentals, while also maintaining a good and direct relationship with the predefined data model in the data model elaboration phase.

As per the available project, the project constraints are centered in the project path medicalScheduleProject/src/Validator/Constraints/. This organization above all facilitated the concentration and verification of understandings about the system's business rules that evolved according to the iterations of the TDD cycle throughout the project.

Attached to the project available in the repository, the benchmark of the tests built along the TDD is also available and very well-defined: "medicalScheduleProject/tests/", as can be seen in Figure 13.

Basically the cores, or groupings of unit tests are available in packages: Entity, Repository, Service, and Validator, which basically define the nature and focus of unit tests.

Both projects are publicly available on GitHub, both the complete source code and the battery of unit tests, including in the same repository (Cardenas, 2023.a), according to the access link below.

To facilitate the reproduction of the project as a whole, it is also available (Cardenas, 2023.b), as a result, and contribution of this project, the complete container has been prepared for easy initialization, also below:

• Download source code from https://github.com/williamCardenas/medicalScheduleProject
• Download source code from https://github.com/williamCardenas/docker-php

References

1. Aniche, M. F., Bavota, G., Trude, C. Gerosa, M. A., Deusen, A. (2018). Code smells for Model-View-Controller architectures. [on-line]. Available in https://pure.tudelft.nl/portal/en/publications/code-smells-for-modelviewcontroller-architectures(55788fc3-56ed-4756-8667-cbf3f1e885db).html. Accessed in Nov. 2022.
2. Aniche, Maurício., Gerosa, Marco Aurélio.(2015). Does test-driven development improve class design? A qualitative study on developers’ perceptions [on-line]. Available in https://journal-bcs.springeropen.com/articles/10.1186/s13173-015-0034-z. Accessed in Nov. 2022.
3. Cardenas, William C.(2023.a). Medical Schedule Project [on-line]. Available at https://github.com/williamCardenas/medicalScheduleProject. Accessed in Nov. 2022.
4. Cardenas, William C.(2023.b). docker-php [on-line]. Available at https://github.com/williamCardenas/docker-php Accessed in May. 2023.
5. Cardoso, A., Aniche, M. (2022) .Test-Driven Development: Teste e design no mundo real com PHP. São Paulo: Editora Casa do Código. Accessed in Oct. 2022.
6. DBever (2023) DBeaver Community Free Universal Database Tool [online] Available in https://dbeaver.io/. Accessed in Mai. 2023.Deusen, Arie. V., Aniche, M., Aué, J., Slag, R., Jong,
7. M., Nederlof, A., Bouwers, E. (2017). A Collaborative Approach to Teaching Software Architecture. [on-line]. Available in https://pure.tudelft.nl/portal/en/publications/a-collaborative-approach-to-teaching-software-architecture(0c7f2aeb-f2d6-4c56-9ab7-5f47f73d133f).html. Accessed in Nov. 2022.
8. Docker (2023) Docker Official Webpage. [online] Available in https://www.docker.com/, Accessed in Apr. 2023.
9. Gaidargi, Juliana.(2022). Como reduzir o desperdício de dados [on-line]. Available in https://www.infonova.com.br/gestao-de-ti/desperdicio-armazenamento-dados. Accessed in Mar. 2022.
10. MariaDb (2023) MariaDB First Disclousure Online Web Portal [online] Available in https://mariadb.org/, Accessed in Apr. 2023.
11. Neves, Glauco Silva.(2014). Uma abordagem reativa de construção de linhas de produto de software baseada em TDD e refactoração [on-line]. Available in https://repositorio.ufsc.br/bitstream/handle/123456789/129071/332126.pdf?sequence=1&isAllowed=y. Accessed in Dec. 2022.
12. Nginx (2023) Website of Nginx Project [online] Available in https://www.nginx.com/, Accessed in Apr. 2023.
13. Potencier, F. (2022) Symfony 6: The Fast Track Official Webpage. Symfony SAS. [online] Accessed in Nov. 2022.
14. PHP (2023) PHP Main Webpage [online] Available in https://www.php.net/, Accessed in Apr. 2023.
15. Robinson, P. (2023) What is ROT (Redundant, Obsolete, and Trivial) Data and How to Manage It [online] Available in https://www.lepide.com/blog/what-is-rot-data-and-how-to-manage-it/, Updated On - May 26, 2021. Accessed in Mai. 2023.

History

• 21^st May, 2023 - Document creation
• 23^rd May, 2023 - Textual revision
• 26^th May, 2023 - First revision and validation
• 27^th May, 2023 - Improve images presentation
• 28^th May, 2023 - Including validation process details
• 29^th May, 2023 - Document submit