Under Ideal Circumstances, the following test practices should be followed.
We will use PHPUnit to test each method we add to our REST interface. We will use a small copy of the database that is solely used for these tests. The previous iteration of this project included multiple unit tests, so our application must also pass all existing tests.
Integration and System testing
If we chose to do so, integration testing would be conducted using Jenkins to test the interactions between our back-end and the various clients such as our website and mobile apps. At the end of each development cycle the system would be in a stable state after passing all the test cases.
The client will test the website and mobile app every week at our scheduled meetings to approve or suggest changes to new functions.
If we chose to do so, users age 12 and older would be used to test our mobile app interface using various types of smart phones (iOS, Android, etc…). Researchers and education professionals would be specifically targeted to make sure access to their desired tools and data would be simple and comprehensible. We would also use our client himself to test the admin page for the application to make sure the information he needs is easily accessible and able to be changed.
Our Test Practices
Because the vast majority of this project focused on building an interface around a relatively simple set of HTTP requests, the majority of testing for this project was manual to make sure that the interface functioned properly. These basic functionality tests were checked for correctness by using browser tools to watch the HTTP requests and responses to come back. As a final check, the database itself was viewed via phpMyAdmin to ensure that the values entered in the smartphone and desktop screens to see if they went through properly.
Mobile App Interface Testing
The mobile app user interface was tested in the following manner. Go manually through each input field, try to put in an out of bounds value and see if the app will correct you, if it does then change it. At the end of the test hit submit, and see what errors or complaints it has then. Correct the errors given to you then try to submit again. This process is repeated until all out of bounds values are fixed. After the survey is submitted use phpMyAdmin or the Administration tools to confirm the site exists.
Aspects of the app that did not specifically depend on the functionality of Cordova plugins and cross-domain HTTP requests, such as the visual appearance and the input value checking, were done in a browser whenever possible.
Administrative Page Testing
This testing proceeded in much the same as as the mobile app did, however the use of the Firebug add-on for Firefox made it easier to see what was going on behind the interface. Different browsers were then used to see if the information looked similar on all of them. It should be noted that per the client’s allowance, the Administration page is mainly designed to work on relatively large monitors.
Testing the API
Testing the API is done manually by submitting HTTP requests using a service such as PostMan for Google Chrome or RestClient for Mozilla Firefox. A full accounting of the API and it’s methods can be found on a Google Spreadsheet who’s link can be found with the Design Document
To test submission_full.php, send the following two JSON objects as the body in a POST request. The first two should create new “order” instances in the database, and the last should create a new “survey”.
“orderArthropod”:”Spiders (Araneae; NOT daddy longlegs!)”,
“orderArthropod”:”Caterpillars (Lepidoptera larvae)”,
“orderNotes”:”I’m a little part two”,
“timeStart”: “2015-11-03 11:59:59”
To test Survey_Update.php, submit the following JSON object as the body in a POST HTTP request. This should update the existing entry in the clean surveys table.
“surveyID” : 21330,
“userID” : 55,
“siteID” : 8892359,
“circle” : 1,
“survey” : “E”,
“temperatureMin” : 50,
“temperatureMax” : 40,
“plantSpecies” : “Broad Leaf Quesadilla”,
“mod_notes”: “this is a test”,