D3. Test Plan

  • unit testing: database, functions (code level), requests.
  • integration and system testing: verification of all functions of the system as a whole (presets, curve IDs, custom values, feedback, logs).
  • descriptions of tools used: pytest, MongoDB, pymongo
  • descriptions of types of end users: our only user is the researcher, but implementation of testing will be developed to facilitate future use for other developers.

PART 1: If we had all the time we really needed:

Unit Testing:

For the existing Model and Motor classes, we will add tests to see if the motors are being activated. With the Model class, we will add tests to see if the functions return the status, row, and column of the motors chosen in the GUI. We would also test the preset processor and control home test to see if the csv are being created as a preset and if control home recognizes certain actions. Many of the other classes do not have return values for the function, making it hard to test. With these tests, we will be able to see if there is an issue with the last motors in the last selected column being able to run.

For the database, we will add testing via pytest to see if the data is being added to the database and if we can successfully perform certain operations with them. This includes creating a database, inserting values in the database, delete values from the database, and selection/projection queries. Since we are incorporating pymongo, we will be testing the python functions created to access the database.

Integration and System Testing:

The Model class includes function that monitor the interactions of various motors. The tests we write for the model class make use of functions from the Motor class to see how they work together when a motor is activated and called in the model. The preset processor class tests to see if a csv has been loaded in as a preset object. The control home class tests to see if actions on this are being recognized.

Performance/ Reliability Testing:

For performance and reliability testing, we would go to the Fluids Lab and test numerous situations. We would test to see if the database results show up in the GUI from the selected preset values and motors. Additionally, we would activate multiple combinations of motors and test to see when the last motor pistons fail to activate, a issue noted by the researchers. We would also come up with settings that work with different curve IDs to see if there are any errors.

Acceptance Testing:

The researchers would test for the problems listed above in the performance section. They would also test if the MongoDB database properly stores the information for the various combinations they run.

PART 2: What we are actually testing:

Unit Testing:

For the database, we will add testing via pyTest (v 7.3) to see if the data is being added to the database and if we can successfully perform the following operations:

  • creating a database
  • inserting values in the database
  • delete values from the database
  • Selection/projection queries
    • Correctly accessing nested values within a json/bson field
  • Since we are incorporating pyMongo, we will be testing the python functions created to access the database.

For the Python models, we will also use pyTest (v 7.3) to test functions in the respective classes.

  • Motor.py and Model.py
    • Is the motor active?
    • Is the model recognizing the active motors?
    • Are all required parameters filled?
  • Ensure exceptions are raised when supposed to
  • Most functions are void, so we assert accessed value equality
  • PresetProccessor.py
    • Are the preset csv files being loaded into a preset object?

Integration and System Testing:

We will also be testing the Model class to observe the interactions between if each motor is grouped together and activated in the same set. We will test to see if the Model identifies which rows and columns have activated motors.

Performance/ Reliability Testing:

Realistically, we will not be able to test every combination of 30 motors to see if there are cases where the last motors do not run. We will create a few combinations and test those (motors activated in first, middle and last columns). We will test the motors with two or three different preset values to see how the curve id affects the movement. We will use specific of presets covering a wider range of values to cover potential edge cases. We will see if the preset csv files (ex/ preset 2.csv) are being loaded and recognized as settings for the motors.

  • Test Cases (for each case turn the motors off after running and test if these motors are not activated)
    • Model test cases:
      • Select Motors: 0,3,5 
      • Select Motors: 0,1,2, 5,10,11,12, 13, 26
        • Activate all motors in column 1 and 2 to test if the last motors activate
      • Select Motors: 2, 5, 8
        • These motors turn are in row 1, testing to see if they get activated
      • Select Motors: 0, 1, 2, 6, 7, 8, 24, 25, 26, 9, 10, 11
        • Test motors on the left, middle, and right
      • Select Motors: 2, 5, 8, 11, 14, 17, 20, 23
        • Motors in row 3

Acceptance Testing:

The researchers will test what was mentioned above in the performance testing.

Expanded document can be found here: https://docs.google.com/document/d/1LekbyPO4JpZHwjjBizyNNKzdgOpIOvXUE-0ZunF_aXw/edit?usp=sharing