On Thu, Dec 03, 2020 at 16:03:55 -0600, Dustan B Helm wrote: [...] > We don’t understand exactly how the testing frameworks are functioning. > With regards to our XML testing, the tests/qemuxml2argvdata/ directory > contains for each test both an xml file and an args file- is this .args > file the expected output qemu command we want to generate from the input > .xml file? Yes, qemuxml2argvtest exercises the XML parser and command line formatter. In case of disk specification there are also provisions for validating whether the generated -blockdev commandline actually conforms to the schema of QEMU. > If so, how do we invoke the VIR_TEST_REGENERATE_OUTPUT flag to create this > .args file, It's an environment variable that the test program is looking for, thus: VIR_TEST_REGENERATE_OUTPUT=1 ./tests/qemuxml2argvtest in your build-directory. (obviously you need to add invocation of the test first and compile the program) > and how concerned should we be about non-disk information > provided in the .xml file as input? Don't worry about them. At the same time there's no use in cramming too much irrelevant non-disk config into the test. Focus rather on adding multiple disks covering various combinations of the configuration to avoid adding multiple test files. > Additionally, since our source name (a > file path) needs to include the NFS export at the beginning, how would we > set up the XML input? Can the file path and NFS export be chosen > arbitrarily? Those are purely unit-tests, thus it doesn't actually try accessing the storage in the first place. That means that it doesn't really matter what path you choose.
