This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-changelog] Add a HOWTO to help writing tests, includes domains with

To: xen-changelog@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-changelog] Add a HOWTO to help writing tests, includes domains with networking.
From: Xen staging patchbot-unstable <patchbot-unstable@xxxxxxxxxxxxxxxxxxx>
Date: Mon, 08 May 2006 13:58:20 +0000
Delivery-date: Mon, 08 May 2006 07:05:27 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-changelog-request@lists.xensource.com?subject=help>
List-id: BK change log <xen-changelog.lists.xensource.com>
List-post: <mailto:xen-changelog@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=unsubscribe>
Reply-to: xen-devel@xxxxxxxxxxxxxxxxxxx
Sender: xen-changelog-bounces@xxxxxxxxxxxxxxxxxxx
# HG changeset patch
# User stekloff@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
# Node ID 39fa9a75d84b93ff1ce9bf4ddf832bc022f28295
# Parent  51908f382f926475834a807a6e7e357212c0db28
Add a HOWTO to help writing tests, includes domains with networking.

Signed-off-by: Daniel Stekloff <dsteklof@xxxxxxxxxx>
 tools/xm-test/Writing_Tests_HOWTO |  134 ++++++++++++++++++++++++++++++++++++++
 1 files changed, 134 insertions(+)

diff -r 51908f382f92 -r 39fa9a75d84b tools/xm-test/Writing_Tests_HOWTO
--- /dev/null   Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/xm-test/Writing_Tests_HOWTO Thu May 04 14:22:38 2006 +0100
@@ -0,0 +1,134 @@
+Writing Tests HOWTO
+One goal for xm-test is to make test writing very easy. Xm-test includes
+a library in lib/XmTestLib that contains all the necessary methods for
+creating and shutting down domains. Include the library in your test by
+importing it:
+  from XmTestLib import *
+1. Tests should be short and single purposed. This means testing as
+   little as possible in a single test. Do not overload tests. The more
+   that's in a test the more difficult it is to track down what failed.
+2. Tests should report as much information as possible when calling
+   FAIL() or SKIP().
+3. A test should report SKIP() only if it cannot be run on the current
+   machine or it makes no sense to run it. SMP tests on an UP system, 
+   for example, may not make sense. Or, there are some tests for
+   para-virtualized guests that won't work on a fully virtualized 
+   guest.
+4. Use the traceCommand() function to run commands on Domain0, the 
+   Xen management domain. This function logs everything, which is useful
+   in case of failure.
+5. Use the domain's console.runCmd method to run commands on a guest
+   domain. This ensures logging and consistency. Please see 'Creating
+   and Using Domains' below for an example.
+6. Tests need to capture and handle libary exceptions such as:
+ - ConsoleError can be raised when sending a command to a console.
+ - DomainError can be raised when a domain is started, indicating
+   a possible configuration error.
+ - TimeoutError can be raised when the traceCommand() method is used.
+7. Tests shouldn't depend on where the test is being run from or the
+   system on which it is run.
+8. Please use the existing tests for a guide, especially:
+ - create/01_create_basic_pos.py
+ - create/13_create_multinic_pos.py
+ - memset/01_memset_basic_pos.py
+ - reboot/01_reboot_basic_pos.py
+ - migrate/01_migrate_localhost_pos.py
+Creating and Using Domains
+Xen domains, both full and para virtualized, are represented by the 
+XmTestDomain class. The class contains methods for starting a Xen domain,
+shutting it down, or destroying it. Consoles, used to execute commands
+on guest test domains, are opened and closed through the XmTestDomain
+class. Devices, which are represented by the XenDevice class, are also
+added and removed using XmTestDomain methods. 
+Here's a simple example for creating a domain, opening a console, running
+a command, and then shutting down the domain:
+1) Create a domain:
+    domain = XmTestDomain()
+2) Start the domain and grab a console:
+    try:
+        console = domain.start()
+    except DomainError, e:
+        if verbose:
+            print "Failed to create test domain because:"
+            print e.extra
+        FAIL(str(e))
+3) Run a command inside the new domain using the console, saving the
+   console log if an error is encountered:
+    try:
+        # Run 'ls'
+        run = console.runCmd("ls")
+    except ConsoleError, e:
+        saveLog(console.getHistory())
+        FAIL(str(e))
+4) Stop the domain, which nicely shuts it down:
+    domain.stop()
+Writing Tests with Networking
+The xm-test suite includes the ability to test networking for domains. 
+Networking is configured at configuration time. While testing NAT and
+routing environments in the future, the current xm-test only supports
+a bridging environment. Xm-test currently only supports a range of
+IPs, the dhcp feature will be added soon.
+The network tests will need to know what IPs to use. IPs are configured
+when you build xm-test. Xm-test uses the zeroconf address range by
+default, If you'd like to set a new range,
+do so at configure time, a netmask and network address must also be defined:
+    # ./configure --with-net-ip-range= 
--with-network-address= --with-netmask=
+The tests will not need to set network information, this is done by 
+the library once it's configured.
+As mentioned above, xm-test's goal is to make writing tests easy. Creating
+domains with networking should also be easy. To create a domain with
+a single network interface, tests can use a XmTestNetDomain object. It
+creates a XenNetDevice for the domain automatically using the pre-configured
+IP information. Otherwise, a network interface can be added to a domain
+prior to starting it (the ability to attach devices will be added):
+    domain = XmTestDomain()
+    domain.newDevice(XenNetDevice, "eth0")
+    domain.newDevice(XenNetDevice, "eth1")
+Here, the domain is created and then the XenDomain factory newDevice
+is called to create a new device of class XenNetDevice to the domain. 
+The xm-test library will automatically assign an IP from the configured
+list, execute ifconfig on the guest domain console, and create an
+alias on Domain0. 

Xen-changelog mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-changelog] Add a HOWTO to help writing tests, includes domains with networking., Xen staging patchbot-unstable <=