On 2/10/20 4:01 PM, Collin Walling wrote: The tests in libvirt's tests directory are all unit tests, and don't run external binaries like qemu - they attempt to test various pieces of code within libvirt in a limited, controlled environment, not requiring any special privileges, and without being subject to the vagaries of external programs. qemuxml2argvtest, for example, calls the code that converts a libvirt domain xml into a qemu commandline, but rather than starting up a qemu process with that commandline, it then compares the generated commandline string to the "known correct" commandline that is stored in a file in a subdirectory of the tests directory (for this example, look at tests/qemuxml2argvdata/*.xml vs tests/qemuxml2argvdata/*.args); this way the success of the test doesn't depend on qemu being installed, the user having the proper privileges to perform all the other things that qemu needs to run, or be subject to a failure due to a bug in the version of qemu running on the build system. Other examples of tests are *xml2xmltest, which parse a test input file, then format the resulting object back to xml, and compare that result with known-correct XML that, again, is stored in a file. Sometimes the code that is being tested calls a function that can't be realistically called from a unit test that is run on random hardware by an unprivileged user (e.g. unbinding a PCI device from its host driver and re-binding it to the vfio-pci driver). In that case, various library functions are "mocked" (by linking in the .o created from *mock.c files - virpcimock.c in the case of PCI device driver binding) to return reasonable values that will allow the libvirt code to be tested without actually needing to perform the "impossible" operation. Anyway, the short answer to your questions is that libvirt's tests directory isn't the proper location (nor is "make check" the proper time) for a test that starts up a qemu process and sends commands to it. Something like that would be better suited for an integration test suite, like the ones that are in the libvirt-tck package (which is a bit dated, but still very useful, as long as you don't mind writing perl scripts :-P) For a unit test in the tests directory, you would want to setup a test harness (blahtest.c) that links in the files containing your code, calls those functions with a fixed set of inputs, then compares the results to fixed known outputs. Along the way you may need to "stub-out" or "mock" various functions that are called by the code under test but can't actually be called in the environment of a unit test.

Much appreciated to you both for the well-written explanations. I'll keep my libvirt tests to mock input/output responses and find an alternative test suite for using libvirt with a real QEMU instance. Thank you for your time! -- Respectfully, - Collin Walling