Testing

1. Testing Strategy

Largely we had to work on testing, to ensure that the github repositories were properly maintained, and to make sure that everyone's projects were suitable and met the requirements needed to be published. Several stages of testing are needed for different sections:

• Functionality testing: This type of testing involves ensuring that each element of the GUI works as intended. For example, buttons should perform the intended action, and menu items should open the correct dialog or perform the intended action
• Usability testing: This type of testing involves testing how easy the GUI is to use. It includes evaluating the layout and design of the interface, ensuring that the interface is consistent throughout, and evaluating how easy it is to find and use different features.
• Compatibility testing: This type of testing involves testing the GUI's compatibility with different operating systems and hardware configurations. For example, an MFC GUI designed for Windows 10 may not function properly on Windows 7 or on a computer with lower hardware specifications. The very point of using MFC was that it could work on all windows versions so checking this at every point was good for peace of mind.

We tested for every team in MotionInput, taking on this work as a four person team was a difficult task so we decided to split the work between the four of us.

2. Unit Testing

Unit testing was necessary for our MFCs for every button created. This was a fairly simple process as the buttons all are meant to write to JSON so all we have to do is check if they are reading from the JSON by running and then returning the output they are receiving and comparing it to the values we expect to get from the config files. As for buttons and items of the MFC that write to the JSON, this was a similar reversed process where we can check the JSON and compare the results that our button messages are returning and checking if the JSONs have properly updated with them.

2. Integration Testing

The integration testing required more nuance. As we are integration testing for every project there were a variety of problems that arose along the way, most notably, was the fact that every team is working from their own build of MotionInput as well as their own adapted MFCs based off our templates. This meant that while we are familiar with the foundations they have built upon we were not immediately familiar with the technical details of their own builds. This meant coming to develop a close understanding of frameworks like mediapipe as we oversaw the upgrade of facial navigation from opencv to mediapipe, or the switch to pyautogui when implementing speech hotkeys.

With new changes and additions made to many different projects in different ways, our testing was key to developing new requirements.txt files including a new one for the main codebase of MotionInput including the general changes needed.