Dan, nice work, thanks.
It would be good to get these tests invoked from the large regression
test suite we use ("XenRT"). Paul has a copy, though I don''t
know
whether he''s had a chance to get it up and running.
Thanks,
Ian
> I have just posted xm-test-0.1.1, available here:
>
> http://static.danplanet.com/xm-test/xm-test-0.1.1.tar.gz
>
> New tests in this release are:
>
> create/03_create_badparm_neg.py
> create/04_create_conflictname_neg.py
> create/05_create_noroot_noram_neg.py
> create/06_create_mem_neg.py
> create/07_create_mem64_pos.py
> create/08_create_mem128_pos.py
> create/09_create_mem256_pos.py
> create/10_create_fastdestroy.py
> help/04_help_long_pos.py
> info/01_info_basic_pos.py
> reboot/01_reboot_basic_pos.py
> sedf/01_sedf_multi_pos.py
> vcpu-disable/01_vcpu-disable_basic_pos.py
> vcpu-pin/01_vcpu-pin_basic_pos.py
>
> Several of these tests have led to patches or bugs being
> filed in bugzilla, including bugs 197 and 216.
>
> * For those who are not familiar with xm-test:
>
> Several of us here at IBM have been working on a framework
> for testing the xen tools, specifically xm. Our goal is to
> provide a way for developers to _easily_ write tests for new
> and existing xm commands.
> We believe that such a test suite will help reduce breakages
> in the user-facing tools when developers modify xm and/or xend.
>
> We would like some feedback from the community on the
> usefulness of our framework, in hopes that it might be hosted
> by xensource so that everyone can contribute tests to help
> harden xm and xend.
>
> * Details:
>
> The framework tests (as well as the support libraries) are
> written in python, which are executed by the standard
> automake "make check"
> facilities. We build a standardized ramdisk that can be used
> for portable test writing, therefore reducing dependencies on
> the test host machine.
>
> The framework library provides several abstractions to make
> common and complex tasks easier for the test writer. For
> example, we provide a domain and console abstraction that
> allows a test writer to start a domU and execute arbitrary
> commands, retrieving the status and output of each. This
> allows a decent amount of automation for verifying that (for
> example) "xm sysrq mydomain s" actually sent the sysrq.
>
> --
> Dan Smith
> IBM Linux Technology Center
> Open Hypervisor Team
> email: danms@us.ibm.com
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-tools mailing list
Xen-tools@lists.xensource.com
http://lists.xensource.com/xen-tools