-
Notifications
You must be signed in to change notification settings - Fork 0
Testing
Testing of this application has been done with unit and end-to-end tests. In addition, testing has been carried out manually, by navigating the web page and actively trying to find bugs.
Unit testing is done using jest. Unit tests are mostly written for back end functionality.
End-to-end testing for this project is done using Cypress.
E2E tests for the start page test that the page can be opened based on whether certain text can be found after trying to visit the front page URL and that the login form shown on the front page works properly. The tests first check that all of the elements of the login form are visible. After that the tests make sure that a user can log in with a username that has been saved before and a matching password. Currently, this is confirmed by making sure that after entering the credentials and clicking the login-button, the log in text is no longer shown. It is also checked that a user cannot login using invalid credentials. At the moment, this is done by making sure that if invalid credentials are submitted using the login-button, the log in text is still displayed on the front page.
In regards to the registration of a new user, the following E2E tests have been implemented. User can register an account by filling all the available fields or just the mandatory ones. Either way the terms and conditions have to be accepted. There are also a few checks in place to make sure that the user can't create an account using a username that has already been registered to the application. In addition, the passwords have to match and the username and password fields can't be left empty.
E2E tests for the list of bacteria test the visibility of the list for normal and admin users. For admins it also tests the addition of new bacteria as well as editing and deleting bacteria from the list. The tests check that an admin can add a bacterium by finding and clicking the Lisää-button. Then the tests check that any added bacteria can be found on the list after being added. It is also tested that an existing bacterium can be deleted. This is done by finding the element containing the bacterium with a given name and clicking the Poista-button inside the same element. After this the code checks that the bacterium is no longer seen on the list. Testing the edit function works very similarly. The Muokkaa-button next to the bacterium to be modified is clicked, the new name is written into the appearing field and the save or cancel button is clicked. After this it is checked whether the bacteria's name has been modified or not, respectively.
The E2E tests test that there is the option to log out of the game. This is done by finding a button with the text 'Logout' and clicking it. After this it is checked that the instruction to log in has become visible. This is done to confirm that the login button has logged the user out of the game.
These automated tests make sure that new in-game tests can be created, modified and deleted. If the name of the test is not unique or if it is too short, appropriate error message notifications are displayed and the test is not saved. A new test can't be added if a type is not selected.
These tests make sure that a new case can be created if the inputs are valid and that the case can be modified or deleted. A few test scenarios have been created to make sure that a new case can't be saved if the name of the case is not unique or if the name is too short. In both situations the tests expect to see a custom on-screen error message that describes the problem. A couple specific tests have been implemented to make sure that changes are not saved if the modifiction form is closed without pressing the save button and that the order of test groups can be switched around.
Case related hints are tested by checking that the add button for hints is visible in the case list, and then by checking the functionality behind it. The add button is clicked, after which a hint is written for one out of the three tests related to the case. The addition is saved and the hint form is opened again to make sure that the hint can still be found. After this the tests check the game side. The correct case is chosen and then the notification behavior of different tests is observed. It is checked that the added hint is only shown for the test it was added for, and also only when that test is the wrong answer.
The tests go through a basic gameplay scenario, where the user first needs to select which case they want to play and then proceeds to click through various options in the actual game page. An appropriate notification is shown when a correct or incorrect sample is submitted. It is made sure that the required tests can only be done in the intended order. After choosing a correct test method, the user is taken to the results tab automatically. After choosing all the required tests, the user can select the dignosis tab and give their answer.
Basic tests have been implemeted to make sure the filtering of credits works as expected using either the student number or the class group. In addition, multiple credits can be deleted by using the filters and pressing the delete button. Only the credits that match the filtering criteria are deleted. All the cases completed by the user, along with other info, can also be viewed by clicking the corresponding button.
These E2E tests check that an admin user can delete individual users by typing the username of the user who is being deleted to the confirmation window that appears after pressing the delete button. The deletion won't happen if the username doesn't match or the window is closed. The tests also check that the administrator can promote other users to admin status or demote admin level users to regular users.
In the profile page view, the tests check that the user can delete their account by clicking the delete button and givin the correct password. If the password is incorrect or the user closes the confirmation window, the account isn't deleted. The tests also check that the profile page contains the expected user information and that the user is able to change their username, password, email, student number and class group if they give the correct password. If the user closes the modification window, changes won't be saved.
Functionality related with images and user getting the email in case of forgotten password, was decided to test without automation.
Test were done on staging server. A user clicks the 'forgot password' -link and get redirected to view where to give ones email address and username. These tests made sure that the user with valid combination of username and email address is to send email with instructions how to sign in. Tests were done to situations with invalid combinations of username and email address to make sure, that in those cases no email is send. These tests made sure that temporary password can be used during the 15 minutes period. Tests checked also that after 15 minutes period password does not work anymore.
Test documentation can be found here. The purpose of these tests were to make sure that adding, changing and removing the images works as wanted. We wanted to be sure that only images that are in use are saved to the server and unused images are removed.