Design

Differences between revisions 4 and 6 (spanning 2 versions)
Revision 4 as of 2009-06-05 09:49:19
Size: 3124
Editor: 63
Comment:
Revision 6 as of 2009-06-29 09:20:33
Size: 3181
Editor: 63
Comment: The project changed the name
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was renamed from Testing/Automation/Desktop/Design
Line 13: Line 14:
The Application class (and all the rest of the applications that inherit from it) have 3 methods, needed for the test suite configuration: setup(), cleanup() and teardown(). The TestSuite class (and all the rest of the applications that inherit from it) has 3 methods, needed for the test suite configuration: setup(), cleanup() and teardown().

The objective of having written a framework for desktop testing automation in Ubuntu is to have a consistent way to write automated tests for all the applications. Furthermore, it makes it easier to write new and reusable tests for applications already available in the framework.

The gnome.py

When adding a new application to the framework, a new class is created in gnome.py module, inheriting from Application.

The ubuntu.py

Same as gnome.py, but for Applications only available in the Ubuntu distribution.

Setup, Clean Up & Teardown

The TestSuite class (and all the rest of the applications that inherit from it) has 3 methods, needed for the test suite configuration: setup(), cleanup() and teardown().

  • setup() is called once when the test suite starts running. It includes the operations needed in the application to leave it in a state where the test cases work.
  • cleanup() is called between test cases in the same test suite. It includes the operations needed to leave the application in the same state as when the test suite started.
  • teardown() is called once when the test suite ends. In includes the operations to leave the system in the same state as before running the suite (killing processes, closing applications, etc)

The Test Runner

Under the bin folder, the mago script, runs the test cases and parses the log.

Syntax:

Usage: mago [OPTIONS]

Options:
  -h, --help            show this help message and exit
  -l FILE, --log=FILE   The file to write the log to.
  --log-level=LOG_LEVEL
                        One of debug, info, warning, error or critical.
  -a APPLICATION, --application=APPLICATION
                        Application name to test. Option can be repeated and
                        defaults to all applications
  -s SUITE, --suite=SUITE
                        Suite name to test within applications. Option can be
                        repeated and default to all suites
  -f FILE, --file=FILE  XML file name of the suite to test within
                        applications.
  -t FILE, --target=FILE
                        Target directory for logs and reports. Defaults to:
                        ~/.mago

For example, to run all the update-manager tests run, from the mago root folder:

./bin/mago -a update-manager

By default, logs go to ~/.mago, but it can be override using the -t option

The classes that run the tests are TestSuiteRunner and TestCaseRunner:

testrunner.jpg

The TestSuite runner parses the XML file and creates an array of test cases to run. Please, read the document on how to create new test suites, to understand the syntax of the XML file.

It then runs the setup() method of the BaseClass, and start running each of the test cases.

After each testcase, it runs the suite cleanup() method, to leave the application in its initial state.

After running all the testcases in the suite, it will call the teardown() method, to close the application and leave the system as before.

Testing/Automation/Mago/Design (last edited 2009-06-29 09:20:33 by 63)