-
Notifications
You must be signed in to change notification settings - Fork 0
Testing
Python: /src/src_learner/tests/
PHP: /src/php/tests/
React: /src/src_react/app/src/
Done through the CI pipeline (read more below)
/src/e2e/cypress/integration/
/postman
Testing was an integral part of our workflow. We decided that we were going to follow the principle of test-driven development. Therefore, unit tests should be written in parallel to the corresponding code parts we were working on. In general, this process worked fine. However, we had some issues in the beginning with the testing of the learner microservice as the library “Pytest” that we wanted to use originally required a certain folder structure. In the end, we decided to use the library “unittest” instead. We tested the React component by using the React Testing Library and mocking the service API with Mock Service Worker. For the service written in PHP we used the library PHPUnit. Apart from unit testing, we mainly focused on system testing as we had just three components that needed to work together. We used the Cypress end-to-end testing framework to simulate real user scenarios from the browser. Real requests are sent to the APIs and real responses are returned and displayed, validating that the integrated components work together as expected from start to end. Since these system tests require the microservices of the system under test to be up and running, we run them together in Docker with Docker Compose. In the beginning of our project we also relied a lot on manual testing with Postman. This was an easy way to visually verify if we were able to send requests and if we were getting the expected output. For the React microservice, manual testing involved running the application and manually selecting or typing inputs in the browser. When just testing the visuals or when the deployed version of the other services were up-to-date, simply running the frontend application locally was sufficient. In other cases, we needed to run the system on Docker before manually testing the application.
We implemented the Continuous Integration Flow (CI Pipeline) via Github Actions (CI tests). Every time a push or pull request happens to the main branch, the tests for all microservices are run inside their respective containers via docker-compose. If any of the tests fail, we catch the exit code of the respective container via the docker-compose up flag --exit-code-from SERVICE and show the failure on github actions. This workflow helped us a lot in making sure that no code with obvious bugs can be pushed or pulled to our main branch. This is particularly important once a continuous deployment pipeline is established to our lightsail environment. Also, it is important to mention that the CI pipeline can only run tests that have been previously written. Therefore, we were able to profit the most from the CI pipeline when we wrote the tests in parallel to new functionalities or if we changed already existing code that had its tests already written.