-
Notifications
You must be signed in to change notification settings - Fork 1
Testing Documentation
In order to speed up the development process and maintain the quality of the code, four testing suites have been developed for this project. A more detailed explanation of the organization of the tests and the purpose of each test suite is provided in the Software Quality Assurance Plan. This document provides a brief explanation of how to run the different test suites using Gradle. The project defines three different Gradle tasks, each of which runs one or more test suites.
The first task runs a single test suite containing unit tests which target the logic of the service class. These tests run in isolation by using a mocked database. To run this suite use the following command from the project's root directory:
$ gradle test
The integration tests for this project are divided into two test suites: business methods integration testing and RESTful service integration testing. However, the two test suites are bundled into the same Gradle task. To run these test suites use:
$ gradle integrationTest
Given that these test suites are somewhat large, an H2 in memory database is used to run them as opposed to a real database. This also prevents errors caused by connection limits. A more detailed explanation behind this reasoning is provided in the Software Quality Assurance Plan.
In addition to the integration tests mentioned above, the project has a fourth test suite with the purpose of testing REST service endpoints provided by other teams in this development unit. This testing suite is much slower than the previous one since it needs make external HTTP requests over the network. To run it use:
$ gradle externalIntegrationTest
In addition to the automated tests, manual tests can be run by using the provided cURL example requests on the project's RESTful service API page. Moreover, the collection of requests can be imported into Postman by selecting "Run in Postman".
After running any of the test suites implemented in the project, a detailed report can be found in:
<project_root>/Backend/build/reports/tests/<test_task_name>
To open the results, just open the index.html file inside of the results folder with any web browser.
In order to automate the deployment process of the project and to ensure that new commits do not break the existing functionality of the code, the Travis CI tool is integrated into the project's repository. This means that every time a team member pushes code to the repository, Travis CI will run a number of tests and deploy the new code to Heroku. To prevent broken code from being deployed, Travis CI will run the test and integrationTest Gradle tasks after every push to the repository.
The external integration tests are not setup to run on Travis CI because those tests can fail for reasons external to the code belonging to this team. Moreover, these tests are significantly slower since the do not use an H2 in memory database like the others.
It should be noted that while Travis CI will always run these tests when new code is added to the repository, members of this team should run all the test suites locally, as explained above, before pushing any changes. Pushing broken code to the repository can delay the work of other team members and should be avoided when possible.
We implemented the integrated, end-to-end testing using Nightwatch.js, a automated web testing framework that utilizes W3C WebDriver API.
Install the below packages using npm install --save-dev
- nightwatch
- selenium-server
- chromedriver
- geckodriver
$ npm test
The Nightwatch test cases are written in a normal Javascript module. In this project, the e2e test cases are written in the test.js file inside src/test/e2e/specs.
We wrote Nightwatch tests to ensure the flow of the Co-Op-Erator application from start to finish behaves as expected. Three main functionalities in the Student viewpoit are covered by the test suite: View Student Information, Register for a Course, and Submit a Document.
After the student is successfully logged in and navigated to the Dashboard page, the WebDriver clicks the Account button on the navigation bar. The test suite then checks whether the student is directed to the StudentInformation page, and whether his/her full name and McGill email address is shown on the page.
On the DashBoard page, the WebDriver clicks the Register Course button. The test suite first checks whether the student is directed to the AcceptanceForm page and whether the form elements are correctly rendered. Then, the WebDriver fills in the acceptance form with relevant course, job, and employer information. After all the fields are filled in, the Submit button is clicked. The test suite then refreshes the Dashboard page and checks whether a course with the corresponding name is correctly added to the Active Course section.
If at least one active course exists, the WebDriver will direct the browser to the CourseInfo page for a specific course, and then navigates to the TaskView page for a specific task under the course. The test suite first checks whether a task is presented with relevant information, and then fills in the Document Submission modal with a Document Name and a Document URL. After it is submitted, the test suite checks whether a document with the corresponding name is added to the Submission History section.