<div dir="ltr">Some quick thoughts about what you could do (points 1 and 2, other paragraphs are more thoughts on making avocado better for such cases):<div><br></div><div>1) For the cases using unittest, you could try to import avocado, if it fails, fall back to unittest.TestCase, such as</div><div><br></div><div>try:</div><div> from avocado import Test as TestClass</div><div> from avocado import main</div><div>except ImportError:</div><div> from unittest import TestCase as TestClass</div><div>...</div><div>Make the classes inherit from TestClass and use</div><div><br></div><div>if __name__ == '__main__':</div><div> main()</div><div><br></div><div>2) For the tests that use the main() entry point, you can refactor main() slightly to separate the argument parsing from test execution, and then implement a small avocado test class that calls the test execution routine. This way the script works standalone and avocado can still run and execute the code. You won't get per dynamically generated test function granularity in the runner. See last paragraph for thoughts on this.</div><div><br></div><div>A more complicated and long term solution would be to make avocado more like pytest, in the sense of making the avocado test runner, on top of running avocado instrumented test classes, also able to run arbitrary callables that have certain names, such as `test_something`.</div><div><br></div><div>A final thought about dynamically generated testing functions: For a test runner that has to inspect the files to figure out what is runnable to generate a list of tests though, dynamic function generation makes things harder. Maybe we can come up with an idea to make avocado aware of dynamically generated callables and somehow make the avocado test loader/runner able to locate them properly and run them as tests.</div><div><br></div><div>Maybe we could try to inspect the current global scope of imported test modules for callables that have certain names and execute them as avocado tests?</div><div><br></div><div>Let me know if this helps.</div><div><br></div><div>Cheers,</div><div><br></div><div>Lucas</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Apr 5, 2017 at 3:01 PM Eduardo Habkost <<a href="mailto:ehabkost@redhat.com">ehabkost@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg"> Hi,<br class="gmail_msg"> <br class="gmail_msg"> I have been writing a few standalone Python scripts[1] to test<br class="gmail_msg"> QEMU recently, and I would like to make them more useful for<br class="gmail_msg"> people running tests using Avocado.<br class="gmail_msg"> <br class="gmail_msg"> Most of them work this way:<br class="gmail_msg"> 1) Query QEMU to check which<br class="gmail_msg"> architectures/machine-types/CPU-models/devices/options<br class="gmail_msg"> it supports<br class="gmail_msg"> 2) Run QEMU multiple times for each<br class="gmail_msg"> architectures/machine-types/CPU-models/devices/options<br class="gmail_msg"> combination I want to test<br class="gmail_msg"> 3) Report success/failure/skip results (sometimes including<br class="gmail_msg"> warnings) for each combination<br class="gmail_msg"> <br class="gmail_msg"> I would like to keep the test scripts easy to run without<br class="gmail_msg"> installing extra dependencies, so I want them to keep working as<br class="gmail_msg"> standalone scripts even if Avocado modules aren't available.<br class="gmail_msg"> Adding a few "if avocado_available:" lines to the script would be<br class="gmail_msg"> OK, though.<br class="gmail_msg"> <br class="gmail_msg"> Do you have any suggestions for making the test result output<br class="gmail_msg"> from those scripts easily consumable by the Avocado test runner?<br class="gmail_msg"> <br class="gmail_msg"> <br class="gmail_msg"> [1] Some examples:<br class="gmail_msg"> <a href="https://github.com/ehabkost/qemu-hacks/blob/work/device-crash-script/scripts/device-crash-test.py" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/ehabkost/qemu-hacks/blob/work/device-crash-script/scripts/device-crash-test.py</a><br class="gmail_msg"> <a href="https://github.com/ehabkost/qemu-hacks/blob/work/x86-query-cpu-expansion-test/tests/query-cpu-model-test.py" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/ehabkost/qemu-hacks/blob/work/x86-query-cpu-expansion-test/tests/query-cpu-model-test.py</a><br class="gmail_msg"> <a href="https://github.com/ehabkost/qemu-hacks/blob/work/query-machines-bus-info/tests/qmp-machine-info.py" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/ehabkost/qemu-hacks/blob/work/query-machines-bus-info/tests/qmp-machine-info.py</a><br class="gmail_msg"> (Note that some of the scripts use the unittest module, but I<br class="gmail_msg"> will probably get rid of it, because the list of test cases I<br class="gmail_msg"> want to run will be generated at runtime. I've even wrote<br class="gmail_msg"> code to add test methods dynamically to the test class, but I<br class="gmail_msg"> will probably remove that hack because it's not worth the<br class="gmail_msg"> extra complexity)<br class="gmail_msg"> <br class="gmail_msg"> --<br class="gmail_msg"> Eduardo<br class="gmail_msg"> <br class="gmail_msg"> </blockquote></div>