-
Notifications
You must be signed in to change notification settings - Fork 1
Test Plan
Our test plan covers our approach to how we are going to test the methods, the format for our test cases, and why we plan to test the libraries currently selected. See our deliverable for specific information.
We started off designing the plan by discussing what methods, functions, and classes, have the most need for testing and then find a way to access them inside of the Moodle directory. After we are able to access the class we then determine a set of five test cases that test the bounds and limits of the function as well as core functionality.
Each test case requires a specific format to be accepted into our main script. We decided to store our test cases each in their own JSON file so that we may easily access them in python. Each test case has seven fields as follows: id, driver, requirement, component, method, input, and expected. id is the test case id and has to be a positive integer, driver links each test case to the driver that is created for it, requirement is purely to display the purpose of the test case with the output, component refers to the class that is being tested, method refers to the specific method within the class that is being tested, input is the input to be passed in to the driver, and expected is what we expect to return from the driver.
We decided to test not Moodle specifically, but their third party libraries that they use inside each of their custom classes. We found when examining Moodle's already built testing framework in PhPUnit that they were not testing any of their libraries that they are importing. Some of the important functionality relies on these classes and if something went wrong, Moodle might have a hard time finding the error since their current testing framework could not find the problem if it was a problem with a helping class. For this reason we decided that our time was best suited to creating a robust testing framework that incorporates as many classes and methods of the third party classes that we had time to implement. We hope that this framework is useful to Moodle and any of the developers who may eventually want to expand on what we have built.