I added a class BaseConfigTestCase to ts_salobj, plus a unit test for it. I then added tests to all ts_config_x packages that have CSC subdirectories for config files (a few don't, yet).
I am not thrilled with the code in BaseConfigTestCase because the methods have a lot of arguments in order to handle special cases (and we may eventually need to add a few more). But it's all in the interest of making each test method succinct, avoiding boilerplate in the tests. I think I have succeeded in that area. It was helpful to write tests for so many CSCs as I found some special cases that helped me refine the code. Any suggestions for improving the API would be welcome.
Note that BaseConfigTestCase.test_standard_configs offers two different ways to find the the CSC package root, which is needed to find the config schema file:
- Import the module and use the __file__ attribute. This is preferred for Python packages that are easily imported (e.g. that only depend on packages available in our standard environment).
- Use the environment variable <PACKAGE_NAME>_DIR, e.g. TS_ATDOME_DIR. This is potentially useful for configurable CSCs that are not written in Python, as well as CSCs with extra dependencies.
Also note that the tests will be skipped if the CSC package cannot be found. I felt this was better than failing since the tests may often be run in a situation where you are modifying configuration files for one particular CSC and don't have some of the other CSCs.
I debated whether to put the tests in the ts_config_x package or the CSC package. I chose to put the tests in the ts_config_x packages because that keeps the tests with the files being tested. Feel free to push back or contact me to discuss the pros and cons if you would prefer that the tests run in the CSC packages.
Pull requests:
Story
I added a class BaseConfigTestCase to ts_salobj, plus a unit test for it. I then added tests to all ts_config_x packages that have CSC subdirectories for config files (a few don't, yet).
I am not thrilled with the code in BaseConfigTestCase because the methods have a lot of arguments in order to handle special cases (and we may eventually need to add a few more). But it's all in the interest of making each test method succinct, avoiding boilerplate in the tests. I think I have succeeded in that area. It was helpful to write tests for so many CSCs as I found some special cases that helped me refine the code. Any suggestions for improving the API would be welcome.
Note that BaseConfigTestCase.test_standard_configs offers two different ways to find the the CSC package root, which is needed to find the config schema file:
Also note that the tests will be skipped if the CSC package cannot be found. I felt this was better than failing since the tests may often be run in a situation where you are modifying configuration files for one particular CSC and don't have some of the other CSCs.
I debated whether to put the tests in the ts_config_x package or the CSC package. I chose to put the tests in the ts_config_x packages because that keeps the tests with the files being tested. Feel free to push back or contact me to discuss the pros and cons if you would prefer that the tests run in the CSC packages.
Pull requests: