Testing
Unit and integration testing
For some of the Keycloak functionalities, we have used Java Unit Testing to actually find out if what we implemented was working properly. For this, we have used a tool called Arquillian ( http://arquillian.org/ ) and we have followed their documentation and online tutorials to see how to use it and create basic unit tests that we can run to make sure authentication is done properly with each change. This endured that we know the app is working after each change we have done.
Code testing
For internal messaging system, we mostly used TDD (test-driven development due to the nature of Rocket.Chat. Every time the code gets updated Rocket.Chat automatically refreshes and rebuilds the project. Therefore, the changes get reflected on the browser when the project gets rebuilt. We did the same for the the other two components, testing the important and core features whenever we added new code or made significant changes. Hence, we could observe the changes on the browser after waiting for project to refresh which led us to use TDD. Basically, we tested the relevant parts of the app after making changes to our code. After implementing some features or changing a large amount of code we tested the app as a whole, focusing on main functionalities of the app to make sure the new code or the code that we removed did not break anything in the app.
Due to lack of documentation and comments, we explored Rocket.Chat’s code by testing the code. To achieve that we simply removed or added code to see what a code snippet was responsible of.
User acceptance testing
We created several test users for each of 5 user permissions which are administrator, senior clinician, junior clinician, clerical and patient to test they only have access to the components and features they are permitted to user.
Test cases
We wrote some special test cases for several occasions to make our testing more organised and efficient. For instance, the following test cases were two of the test cases which we used to test users’ access permissions:
| ID | Test Scenario | Result Expected | Actual Outcome | Test Result | |
|---|---|---|---|---|---|
| 1 | Verify that admin can delete chat groups. | Login as the admin and delete one chat group. Later, login as a senior clinician to verify that the chat group has been deleted. | Admin should be able to delete the chat group, it must be inaccessible by the senior clinician. | The chat group has been successfully deleted by the admin and it has been verified by logging into senior clinician’s account and viewing accessible chat groups. | PASSED |
| 2 | Verify that patients cannot create chat groups. | Login as a patient and try to create a chat group from navigation bar. | “+” sign should not appear hence, prevents patient from creating chat groups. | The “+” sign appeared and a chat group was created. | FAILED |
First test case
As the result of this test case piece that we had written, the first case had passed hence, we achieved to implement that feature successfully. However, the second test failed and this is the reason why we went back to code to find a solution for this bug. When we found the problem and fixed the code, we added this test case again to the next testing process.
This was the result for this particular test case:
| ID | Test Scenario | Result Expected | Actual Outcome | Test Result | |
|---|---|---|---|---|---|
| 1 | Verify that patients cannot create chat groups. | Login as a patient and try to create a chat group from navigation bar. | “+” sign should not appear hence, prevents patient from creating chat groups. | “+” sign did not appear and the patient was not able to create a chat group. | PASSED |
Second test case
We repeated this cycle as we tested our features until we solve the issue. For some test cases which were not resolved for a long time we tried to take a step back and to try a different approach to solve the problem.
The Collaborative Text Editing Tool has been tested on the Microsoft Azure 2016 Server. All the users were able to edit their name and update their colour code, no matter what kind of device/operating system they were using.
Compatibility testing
All three components have been tested on different devices, browsers and operating systems and all of the tests passed.
Responsive design testing
For all three components were tested on different screen sizes including smart phones, tablets and computers with various browsers which confirmed that all our designs were fully responsive and adaptive.
Performance testing
So far, we have tested the Collaborative Editing Tool with more than 10 users contributing at the same time on the same pad, each one of those having a different colour and name. At this point, we didn’t spot any delay in updating the text in real-time. Moreover, all the pads tested saved the text and its formatting options.
We have done similar tests for the messaging and the authentication system and everything is running smoothly. Moreover, we really think that the open-source tools we have used already provide enough performance for everything we needed to achieve.
Security testing
The main point for testing the security was to ensure that we have a secure authentication. This was a critical requirement, as user data should be highly protected. So, we have used a number of penetration tests and tools (from password brute-forcing to SQL injection) to test if there are any flows within the system. However, since Keycloak is a highly secure tool, we managed to pass all the tests successfully. As a final step, we will install an SSL certificate to make everything fully secure and protected, not only for authentication, but also for all the other tools. We think that all the components are secure since they rely on very complex and well-built open source solutions.