Testing Documentation
| Variable | Value |
|---|---|
| SPRING_DATASOURCE_URL | jdbc:postgresql://ec2-54-196-65-186.compute-1.amazonaws.com:5432/dast7ct595n8b8?password=38e45095343af90c5bbba78ebf2454cbe596d2ad6d3a11d7e535fdbbbe96f03a&sslmode=require&user=oqpxbbssnfmpaj |
| Variable | Value |
|---|---|
| Heroku App Address | https://librarysystem-backend-321.herokuapp.com/ |
Overall, testing our repositories and classes proved to be fairly straightforward conceptually, but somewhat difficult when one factors in the learning curve for translating associations, hierarchies and compositions into JPA Annotations and CRUD repositories. Notably, a big point of concern was which classes required repositories and which ones did not. For instance, if one were to refer to the domain model, they would notice the fact that we made use of a few abstract classes. Furthermore, a design decision of ours was to not create CRUD repositories for these classes, as they would not be instantiated on their own. Extending this to our testing cases, we only tested classes that were linked to CRUD repositories, as they usually had their own relational database tables in which their attributes and information were uploaded in. As a result, classes such as User and TimeSlot were not tested in this regard, and rather, had their attributes extended to their subclasses.
Furthermore, another point of contention was the methods with which we wanted to join tables. Since subclass-superclass relationships were quite prominent in our model, an issue that arose was the use of discriminators. To clarify further, we decided to create a set of larger tables which contained subclass information, but would distinguish these subtypes through a discriminator column (where each row would clarify which type of object it is). This posed some difficulties, notably, with some faulty tables which did not recognize the discriminator column and would constantly try to input null values instead. This would result in our testing application failing. Ultimately, this issue was quelled by deleting our old tables off of our database and refreshing the system with some new tests. Furthermore, this meant that as long as if we did not change the format of the columns after doing this, the system should have no issue clearing/adding new entries with a similar format in the future.
Overall, the tests work in a fairly linear matter. Before each test, the repositories that we loaded in our project's database are cleared to ensure that remnants of previous tests are not present in the code. Furthermore, after doing this, the program will run each test method. Each test method is strictly focused on testing one repository at a time. An instance of the class that the repository is based on is initialized, its attributes are declared and set, and the item is saved in the database. Furthermore, the instance itself is set to null and is assigned to become the entry we loaded into the table, testing to see if the write and read methods for the database are running properly. After this is done, the attributes of this database object are compared with all of the attributes we set for the object in the beginning, asserting true if they are the same. This process is identical for all of our tables.
