[libvirt] [PATCH] Skip some xen tests if xend is not running
Jim Fehlig
jfehlig at novell.com
Thu Jul 7 23:39:52 UTC 2011
Eric Blake wrote:
> On 07/07/2011 04:00 PM, Jim Fehlig wrote:
>
>> Currently, the xen statstest and reconnect tests are only compiled
>> if xend is running. Compile them unconditionally if xen headers
>> are present, but skip the tests at runtime if xend is not running.
>>
>> This is in response to Eric's suggestion here
>>
>> https://www.redhat.com/archives/libvir-list/2011-July/msg00367.html
>> ---
>> configure.ac | 24 ------------------------
>> tests/Makefile.am | 12 ++++--------
>> tests/reconnect.c | 11 +++++++++++
>> tests/statstest.c | 12 ++++++++++++
>> 4 files changed, 27 insertions(+), 32 deletions(-)
>>
>
> Nice - it removes more lines than it adds, while still improving
> compilation coverage!
>
>
>> +
>> + /* skip test if xend is not running */
>> + cmd = virCommandNewArgList("/usr/sbin/xend", "status", NULL);
>> + if (virCommandRun(cmd, &status) == 0 && status != 0) {
>>
>
> If we fail to run the command for external reasons (such as no
> /usr/sbin/xend binary, or the status command was killed by a signal
> instead of a normal exit), we probably still want to skip this test.
> How about this (in both tests):
>
> if (virCommandRun(cmd, &status) != 0 || status != 0) {
>
>
>> + virCommandFree(cmd);
>> + return 77;
>>
>
> I forget we had a macro to avoid the magic number: s/77/EXIT_AM_SKIP/
>
>
>> + }
>> + virCommandFree(cmd);
>> +
>> /* Some of our tests delibrately test failure cases, so
>>
>
> Hmm, while you're touching this, how about s/delibrately/deliberately/
>
> ACK with those changes.
>
I've pushed this with your suggestions.
> Oh, and our testsuite has a cosmetic bug. After applying your patch, I
> see this during 'make check':
>
> TEST: xencapstest
> .......... 10 OK
> PASS: xencapstest
> SKIP: reconnect
> TEST: statstest
> 0 FAIL
> SKIP: statstest
>
> Bonus points for fixing up that output to say SKIP instead of FAIL and
> to align it correctly (but that can be a separate patch).
>
I'll look into it.
Thanks,
Jim
More information about the libvir-list
mailing list