Skip to content

Commit

Permalink
Update REPORT.md
Browse files Browse the repository at this point in the history
Added Maintainability and Reliability
  • Loading branch information
PramithKodali authored May 20, 2024
1 parent 5fc2dd7 commit 931008e
Showing 1 changed file with 7 additions and 6 deletions.
13 changes: 7 additions & 6 deletions report/REPORT.md
Original file line number Diff line number Diff line change
Expand Up @@ -114,18 +114,19 @@ To add a new test, create a new test function inside the "backend.test.jest" fil
The repo features fully functioning integration tests which is capable of testing both the frontend and the backend. These tests utilise Python Unittest and is designed to be fully maintainable and accurate. They can be found inside the integration_tests folder and are separated into frontend and backend folders. Each folder contains files prefixed with test_ which is followed by an identifier for the specific test type. The tests are designed to test the backend fully and covers every route and cases within the route. The tests are designed to be easily readable and extendable with new tests. Tests for the backend are divided into different files based on the route they are testing. The tests which cover base functionality (all tests excluding FullSuite) verify the Db before executing the route. Then it sends the request, verifies the response and response code and finally verifies the changes made in the database. By integrating the tests with the database, we are able to verify the changes and ensure it's success. The FullSuite tests are designed to test the backend in more real world scenarios and ensures the backend is functioning as expected. To do this we make multiple requests within a test and verify the responses and changes made in the database. he tests work by spinning up 3 containers (backend, database and the container running the tests). These containers are defined inside the "docker-compose.yml" file located inside the "integration_tests" directory. The tests can be run locally or in the GitHub Actions. Currently they are set to run in the GitHub Actions on every push or PR to the main branch. However, developers can manually run it as well by selecting run workflow and selecting the branch they want tested. Another important note is that the database must be cleared to ensure that no persistent data is left over. This is automated as part of the test.sh script. When the tests are run at the end it provides a short overview on how many tests passed and failed. To find more details about the test that failed scroll up until you find the test that failed and it will provide more information on why it failed. All tests (excluding the Full Suite testing) are designed to have a few asserts and to verify the function is working as expected. Each function currently has success tests which ensure normal functionality. As part of the integration tests a frontend test suite has also been made using playwright. These tests can be found inside integration_tests/frontend. These tests verify the frontend is working as expected. Although these are not comprehensive it does provide a good starting point for testing the frontend. The tests can be run by executing tests.sh inside integration_tests. To find more information specific to adding tests or maintaining the tests please refer to the docs/TESTS.md.

### Quality Attributes

#### Availability


#### Reliability
There were numerous techniques employed to achieve the high level of reliability that we had set at project conception. In the project proposal it was outlined to achieve the necessary level of reliability, the project should have unit tests that thoroughly covers the core functionality of the system. These tests should ensure that the system maintains expected behaviour. We used test driven development to implement the unit and integration tests that cover the entire functionality of our application and previously mentioned in the testing section. These tests are then used in a GitHub workflow to ensure that every time a code change is pushed to main the tests run to ensure the core functionality works before the code reaches main.

Secondly, by deploying our application to Amazon Web Services, we remove the necessity to ensure the webservers running our application are working correctly. Through the shared responsibility model AWS is responsible for the infrastructure such as the hardware, software and networking that run AWS Cloud services. We then using terraform ensure the containers we deploy are reliable on AWS.

#### Maintainability
Maintainability has been achieved primarily by the abstraction of code and layers. In the backend we have separated the functionality behind the endpoints in their own files and services to allow for easier maintainability. This also allows us to easily improve our architecture in the future by converting to a microservices architecture for better maintainability. We also use docker and containerization to separate the frontend, backend and database into three independent containers that communicate with each other through highly [documented](../docs/HANDSHAKE.md) API calls over HTTPS. This level of separation allows for ease of use and ease of access as each container has vastly different responsibilities.

We also made the effort to use the same programming language for both the front and backend. This acts as a redundancy that even if our documentation is unable to effectively communicate our decisions or is no longer update, the developer should be easily able to read the codebase and understand the importance and inner working of each component of the system.

The core functionality of UniBasement and the way it has been designed, allows for future use with minimal maintenance needed.

For example, adding new courses and/or exams is not something done with code, and as such can be done by someone with no technical understanding of the underlying system. This abstracts the course/exam maintenance off the developers and to the students/admins leaving just new features and bug fixing to developers.

The containerization of UniBasement allows for two different code bases / containers, that communicate to each other with highly [documented](../docs/HANDSHAKE.md) API calls. This not only allows for ease of use, but a way to understand what is expected on either end without having to search through the entire code base. Another key factor to consider is that both the front-end and the back-end is written in the same language, which if the documentation fails (not able to communicate effectively) or is no longer up to date, the developer should be able to understand each component of the system.

## Reflection

Expand Down

0 comments on commit 931008e

Please sign in to comment.