Testing - HeartUoA/HeaRT GitHub Wiki
Testing code is an integral part of any application suite and with HeaRT, that case is no different. Agile Monkeys aimed to develop code that is robust and performs exactly what is intended. With testing web applications, there is an additional component alongside traditional unit tests surrounding code that executes on a server. HeaRT is built with a feature rich user interface and with time complexities, unit testing a frontend interface designed with React would be very difficult if the team wanted to get a finished product within 4 sprints.
The following areas were covered with enough decency within the time scope afforded to us:
1. Functionality Testing
This process involved testing all links to the web application in order to ensure that the business logic of HeaRT was performed as intended. To do this, the team checked outbound links, internal links, forms validation and cookie testing to ensure that the flow was maintained throughout every pull request. Our team had a principle to not break main and every PR added to the main branch was expected to be feature complete (or at most, not half baked).
2. API Testing
HeaRT relies on server side communication in order to perform data persistence and retrieval. The server is an integral part to the flow of the game and it was critical to ensure that all endpoints were tested and everyone on the team was aware of which endpoints were exposed. To achieve this, we set up a Postman script which contained a template of all endpoints being added and a template request. This additionally allowed for anyone hooking up the frontend to the server to know exactly what was expected in the API request.
3. Security Testing
User data, in any scenario is critical. It was our Product Owners request to ensure that data integrity and privacy was maintained. To achieve this, the team implemented JWT authentication and enforced private API endpoints for anything outside creating and logging into a user profile. With each API request (such as to create a course), the user was expected to pass a secret JWT session cookie which contained their user data cryptographically signed by the server and served to them when they initially logged in. So, with any endpoints created on HeaRT, the team spent time testing that data not owned, created, or permitted by that user is never modified by anyone else. It was ensured that all API requests passed via an authentication middleware before even hitting the controller layer of the architecture.
4. Unit Testing
The server side code was written with unit tests validating all critical paths that the endpoint could encounter. Although there was no such restriction on the frontend code due to its UI heavy nature, all server side code was expected to have accompanying unit tests in order to ensure business logic validity and security which was tested by the Continuous Integration pipeline set up on GitHub Actions.
5. Database Testing
Although minimal, there were certain steps taken to stress test one of the most critical components of HeaRT, the database. Testing activities included: checking for any errors while executing database queries, evaluating database integrity when performing CRUD operations, checking the response time of the queries being executed and ensuring that none take longer than the average expected time for a user to wait for network requests, and ensuring that the test data being retrieved from the database is accurately reflected in the front end interface.
6. Cross Compatibility Testing
This area was particularly minimal as HeaRT is not designed to be played on a mobile device. Therefore, at minimum, the team ensured that HeaRT was easily viewable on various desktop screen sizes. To achieve this, we utilised a responsive layout afforded to us by the use of CSS and AntD.