Right now, radex has some example scripts/programs that show some of its functionality. These examples tend to be a good place for newcomers to the project to learn how to use radex and what capabilities it has. Therefore, it is imperative that they remain working.
We should find a way to add these examples to our automated testing so that they stay up to date and working as we continue to iterate on our API. Currently, to run the the examples, they must be built when building the C++ client by passing the -DBUILD_EXAMPLES=ON option, installing the python client (also potentially done via cmake), and then running the driver.py script in the appropriate runtime (sometimes dragon is required, sometimes it is not).
I would purpose adding a new tests/examples directory where we find or list all example driver scripts, run them in the appropriate runtime (or skip them if the runtime is not available), and then finally do some basic checking on the overall workflow output (return code is zero, stdout matches some templated output file, etc.). If these checks pass and the rest of the unit tests do as well, we can be reasonably sure that the examples work and that users are free to continue using them as references.
Right now, radex has some example scripts/programs that show some of its functionality. These examples tend to be a good place for newcomers to the project to learn how to use radex and what capabilities it has. Therefore, it is imperative that they remain working.
We should find a way to add these examples to our automated testing so that they stay up to date and working as we continue to iterate on our API. Currently, to run the the examples, they must be built when building the C++ client by passing the
-DBUILD_EXAMPLES=ONoption, installing the python client (also potentially done via cmake), and then running thedriver.pyscript in the appropriate runtime (sometimesdragonis required, sometimes it is not).I would purpose adding a new
tests/examplesdirectory where we find or list all example driver scripts, run them in the appropriate runtime (or skip them if the runtime is not available), and then finally do some basic checking on the overall workflow output (return code is zero, stdout matches some templated output file, etc.). If these checks pass and the rest of the unit tests do as well, we can be reasonably sure that the examples work and that users are free to continue using them as references.