search

ipa320 / araig_test_stack

Apache License 2.0
0 stars 4 forks source link

Component testing guidelines #3

Closed ipa-kut closed 3 years ago

ipa-kut commented 3 years ago

Some suggested points to check when testing the components (interpreters, runners, calculators etc..): @ipa-rwu and @ipa-alb : Please feel free to add some more points

  1. Functionality - Test all combinations of inputs
    1. Purpose - Too big? Too small? Reusable? Model level appropriateness.
    2. Rate - Check functionality at different topic rates and combinations of rates (also test latched topic response)
    3. Parametrs & Arguments - What happens if some are missing?
    4. Shutdown - Give kill signal (Ctrl + C) at different stages of execution, see how gracefully it shuts down. Make sure no hanging threads.
    5. Reset Ready - If states are reset, can the component resume original state?
    6. Verbosity - Too much? Too little? Using ros logs instead of native console prints?
    7. Dependencies - Can some deps be avoided? Are deps dependable across ROS destros? Easy to install? Included in package.xml?
ipa-kut commented 3 years ago

Identify subsystems, develop protocols, write mocks for subsystems.

Ex: Write a mock sensor publisher to test the marvel interpreter and braking time. The mocked sensor can publish sinusoidal sensor data, sends the trigger signals and gives ground truth. This is compared to the calculator over >10 trials, and accuracy of system is calculated.

ipa-kut commented 3 years ago

Testing the goal interpreter requires move_base. Consider mocking it.