At time of writing we have 2 spots in the tests/python/dragon/test_wait_for_item.py tests that require us to find the polling interval of radex to ensure that "wait for item" type test return within a reasonable amount of time.
|
# FIXME: We should expose the poll rate through the `radex` namespace |
|
# rather than looking for magic env vars in the tests |
|
_POLL_INTERVAL = os.environ.get("RADEX_POLL_INTERVAL", 100) / 1000 # seconds |
|
# FIXME: We should expose the poll rate through the `radex` namespace |
|
# rather than looking for magic env vars in the tests |
|
poll_rate = os.environ.get("RADEX_POLL_INTERVAL", 100) # milliseconds |
This method, of checking for configuration constants in environment variables, means that if we ever decide to update the expected name of the environment variable or the default value or decided to add a new configuration source, we must also remember to update these tests as well. Similar problems exist for any user code that may rely on these configuration values.
We should consider adding a way to get these configuration values in Python simply by querying from the radex name space. E.g.
import radex
poll_interval = radex.get_poll_interval() # returns a integer (unit TBD) or `datetime.timedelta`
This brings us closer to parity with our C++ interface (which can find these constants in header files), and allows us to uncouple these tests (and any future user code) from the exact way a configuration constant is found. This can be done for all configuration constants, not JUST the default poll interval. This is just a good place to start.
At time of writing we have 2 spots in the
tests/python/dragon/test_wait_for_item.pytests that require us to find the polling interval of radex to ensure that "wait for item" type test return within a reasonable amount of time.radex/tests/python/dragon/test_wait_for_item.py
Lines 23 to 25 in 0aa1c62
radex/tests/python/dragon/test_wait_for_item.py
Lines 53 to 55 in 0aa1c62
This method, of checking for configuration constants in environment variables, means that if we ever decide to update the expected name of the environment variable or the default value or decided to add a new configuration source, we must also remember to update these tests as well. Similar problems exist for any user code that may rely on these configuration values.
We should consider adding a way to get these configuration values in Python simply by querying from the radex name space. E.g.
This brings us closer to parity with our C++ interface (which can find these constants in header files), and allows us to uncouple these tests (and any future user code) from the exact way a configuration constant is found. This can be done for all configuration constants, not JUST the default poll interval. This is just a good place to start.