Unit Testing

We did unit testing in two separate areas: the front end and the back end.

To test our React front end front end, we decided to use ‘Jest’, a test framework built by Facebook. We chose to use this because it is built into the ‘create-react-app’ package, which is what we used to create our project, so we knew that there were no extra dependencies or alterations we needed to make to start testing. Moreover, we were interested in using snapshot testing, which is something jest makes very easy to do. Finally, jest is very efficient and runs very quickly due to its parallel testing. More details about this can be found here:

An alternative we were considering was Mocha, which is older than jest, so we thought it might have better documentation, examples and tutorials online. However, we ultimately decided not to use this because it seemed to be harder to set up, as it would need to be configured, whereas Jest would not.

We learned how to test using the official react documentation, as it had a lot of good information about how to properly set up the tests, and good coding practices. For example, we knew that it was good practice to create a test set up and tear down, and looking this up in the docs showed us how to set it up properly using jest. However, we did actually learn a lot of new information when following the docs, as there were additional features that we did not know about that were specific to React testing, such as using the helper ‘act()’, which basically ensures that "all updates are applied to the DOM before making any assertions", and labeling your tests with the "it function".

The library we used to test the backend is called TestClient. The TestClient can be instantiated by passing the app into the constructor. After that, we can use the instance to test our api endpoint just like what we do with the “request”, which is very convenient. For example, if we want to test the status code returned from an endpoint using GET method. We firstly make the request by typing "response = client.get('/testapi')", then we can use "assert" statement to check the status code by typing "assert response.status_code == 200"

Compatibility Testing

We are aware that there are numerous online tools that can help with compatibility testing, such as LambdaTest, but we chose not to use them for two major reasons. Firstly, as I have mentioned before, our tool is a proof of concept project. It is meant to demonstrate functionality rather than be a finished product, so trying to check the programs compatibility with a wide variety of obscure browsers seemed like a bit of a waste of time. Therefore, we instead tested the software manually on different devices and browsers to check that it worked properly. These are listed below.

1. Mac OS: Safari, Chrome, Firefox
2. IOS: Safari, Chrome
3. IPad OS: Safari, Chrome
4. Android: Chrome
5. Windows 10: Chrome, Firefox

User Acceptance Testing

Our primary goal was to demo our final prototype to current IHE students to find out their opinion of the tool, as they would be perfect pseudo users to test the tool on, having been prospective students themselves. Unfortunately we did not get the chance to interview them, as our group has been greatly impacted by the coronavirus, as many of us left the country. However, as a substitute, we had the honor of presenting our tool at a IHE education delivery group meeting, which contained important stakeholders who worked under the IHE. This was beneficial as they helped critique the tool, although they were more concerned with the functionality than the UI design.

To compensate for this, we reached out to our own friends and family to evaluate the tool instead. In the interest of time and efficiency, we decided to only interview 4 people, as the Nelson Norman Group’s research suggests 4-5 testers are the optimal number of testers. We tried to interview people who are the same age as our prospective users would be. Their feedback is shown below: