You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description pulled from parent issue. This sub-issue is to create the MM checkout test specifically.
There is a need to create quick running app checkout tests that can be run in a pipeline to verify that commands were not broken by a pending PR.
The following needs to be done:
Create a "group" for each app that, in addition to the setup and teardown functions, has one test in it.
- Each group's file name will follow the naming convention: [app]_checkout.py where [app] is either cfe_[short app abbreviation] or cfs_[short app abbreviation]
- There may be exceptions to any of these. Be flexible and do what you think needs to be done to accomplish the overall goal: Quick running test that sends all (or as many as possible) commands to verify no command receipt has broken.
- There should be minimal waiting between commands. Do not wait for confirmation of the command being accepted after each command, instead check for the final total expected command count at the end (quick execution is the goal!)
- The test will primarily verify that all commands of the app are accepted via command counter (or as many commands as possible). If there are other known telemetry items that should be a certain value and it will not slow the test down you can add them at the end after the command counter verification using the COSMOS check() call, not the wait_check(), as the later would wait too long.
- The wait for the total command count should be either the length of 2 expected telemetry packets, or 10 seconds, whichever is longer. for example most telemetry packets are sent every 4 seconds (4Hz), so a proper wait time is 10 seconds at most for those. While a packet that has a 6Hz period would need to wait 12 seconds. Offsets into the time period does not matter, the point is to see the correct value after one new telemetry packet, any wait for a failure of longer than 2 packets is too long.
- Preservation of environment is not a concern other than not to ruin the system for later apps. Files created can be left on the system. No need to clean-up after the test.
- Only execute setup commands required for the needed commands, these should be limited to the CFE or the app under test. Use the existing system files where possible if file manipulation is needed.
- Order of the commands should not be strict and does not need to follow the order of what is in the app or cmd/tlm definitions. Change the order of the commands as necessary to reduce the need for setup commands. For instance, the FM command order can be done in a way where an exiting file can be copied to a new name or directory can be created, then later FM commands can all use those as they get manipulated throughout the test. Plan ahead to reduce the need to repeat commands.
Description pulled from parent issue. This sub-issue is to create the MM checkout test specifically.
There is a need to create quick running app checkout tests that can be run in a pipeline to verify that commands were not broken by a pending PR.
The following needs to be done:
- Each group's file name will follow the naming convention: [app]_checkout.py where [app] is either cfe_[short app abbreviation] or cfs_[short app abbreviation]
- There may be exceptions to any of these. Be flexible and do what you think needs to be done to accomplish the overall goal: Quick running test that sends all (or as many as possible) commands to verify no command receipt has broken.
- There should be minimal waiting between commands. Do not wait for confirmation of the command being accepted after each command, instead check for the final total expected command count at the end (quick execution is the goal!)
- The test will primarily verify that all commands of the app are accepted via command counter (or as many commands as possible). If there are other known telemetry items that should be a certain value and it will not slow the test down you can add them at the end after the command counter verification using the COSMOS check() call, not the wait_check(), as the later would wait too long.
- The wait for the total command count should be either the length of 2 expected telemetry packets, or 10 seconds, whichever is longer. for example most telemetry packets are sent every 4 seconds (4Hz), so a proper wait time is 10 seconds at most for those. While a packet that has a 6Hz period would need to wait 12 seconds. Offsets into the time period does not matter, the point is to see the correct value after one new telemetry packet, any wait for a failure of longer than 2 packets is too long.
- Preservation of environment is not a concern other than not to ruin the system for later apps. Files created can be left on the system. No need to clean-up after the test.
- Only execute setup commands required for the needed commands, these should be limited to the CFE or the app under test. Use the existing system files where possible if file manipulation is needed.
- Order of the commands should not be strict and does not need to follow the order of what is in the app or cmd/tlm definitions. Change the order of the commands as necessary to reduce the need for setup commands. For instance, the FM command order can be done in a way where an exiting file can be copied to a new name or directory can be created, then later FM commands can all use those as they get manipulated throughout the test. Plan ahead to reduce the need to repeat commands.