Ubuntu Wiki

As explain in the Design document, a TestSuite in the Ubuntu Desktop Testing framework contains two different files, a .py file with the TestSuite class and methods and a .xml file, with the description of the TestSuite.

When writing a new TestSuite with the Ubuntu Desktop Testing framework, based on already available applications in the library, create the .py file and the .xml based on the following templates (available classes):

Python File

   1 import ldtp
   2 import ldtputils
   3 
   4 # import the necessary Ubuntu applications
   5 from desktoptesting.ubuntu import <BaseClass>
   6 # import the necessary GNOME applications
   7 from desktoptesting.gnome import <BaseClass>
   8 
   9 class <SuiteClass>():
  10 
  11     def setup(self):
  12         #setup code, put here what happens at
  13         #the beginning of the testsuite
  14 
  15     def teardown(self):
  16         #teardown code, put here what happens when
  17         #the testsuite finishes
  18 
  19     def cleanup(self):
  20         # Add here what happens between test cases,
  21         # i.e. cleaning logs and/or temp files
  22         pass
  23 
  24     def <method1>(self, arg1, arg2):
  25 
  26         self.do_stuff()
  27         self.do_stuff()
  28         
  29         if do_some_check() == FAIL:
  30             raise AssertionError, "Human readable message"
  31 
  32 if __name__ == "__main__":
  33     <example_test> = <SuiteClass>()
  34     <example_test>.run()

The python file contains the code for the test script. We are going through the script lines, explaining each of them.

• 1,2: Needed only when calling ldtp functions directly in the script.

• 4: BaseClass is the Application class in the desktoptesting library (Gedit, Seahorse, ...)

• 6: SuiteClass is the name of the class for the giving suite. Anyname would do, but a descriptive name is better.

• 6: BaseClass, again, is the applicaiton class in the desktoptesting library. The Suite class will inherit from this one.

• 7: method1. A suite can contain as many methods as needed. This is were the script code is written.

• 9,10: call any methods in the BaseClass to perform the script actions

• 12: Do some check after the script to assert that it passed. Raise an AssertionError if something failed.

  • You can also return a list on success (message, screenshot), that will log a message and will grab a screenshot. message will be a string, screenshot, the path of screenshot file.

• 15: The main class just creates an instance of the SuiteClass and calls the run method. The TestSuite runner will do the rest.

XML File

<?xml version="1.0"?>
<suite name="A name for your suite">
 <class>{module_name}.{SuiteClass}</class>
  <description>
    A nice description about the purporse of the test suite
  </description>
  <case name="{NameCase1}">
    <method>{methodcase1}</method>
    <description>A description of the first testcase</description>
    <!-- args of the case method -->
    <args>
      <arg1>contentofarg1</arg1>
      <arg2>contentofarg2</arg2>
      ...
      <argN>contentofargN</argN>
    </args>
  </case>
  <case name="{NameCase2}">
    <method>{methodcase2(couldbethesameas1)}</method>
    <description>A description of the second testcase</description>
    <args>
      <arg1>contentofarg1</arg1>
      <arg2>contentofarg2</arg2>
      ...
      <argN>contentofargN</argN>
    </args>
  </case>
</suite>

The XML file is almost self-describing. The most important parts of it are explained below:

• The suite root node has a name attribute, with the name of the suite.

• The <class> tag contains the module name of the .py file and the SuiteClass class (same as the one in the .py file)

• The <description> tag contains a human readable description of the purpose of the suite.

• For each case in the suite we will add a case child node with the following content:
  • A name attribute with the name of the case

  • The <method> tag contains the name of the method of the SuiteClass to run for that particular test case.

  • The <description> tag describes the test case in a human readable manner.

  • Add a new child tag to the <args> tag with the argument name of the test case method.

    • i.e. if the method signature is something like:

         def my_method(self, name, surname):

      then, the <args> node of the XML file will contain something like:

         <args>
           <name>John</name>
           <surname>Smith</surname>
         </args>

      That allow us to use the same method for different test cases.