Difference between revisions of "Platform Team/Server Kit/sugar-unit"
m (→Summary) |
|||
Line 1: | Line 1: | ||
== Summary == | == Summary == | ||
− | + | The project is intended to: | |
* Provide high level code, based on Python unittest library, to simplify Sugar related development; | * Provide high level code, based on Python unittest library, to simplify Sugar related development; |
Revision as of 16:57, 10 November 2011
Summary
The project is intended to:
- Provide high level code, based on Python unittest library, to simplify Sugar related development;
- Emulate regular Sugar client behaviour to help, e.g., with testing Sugar Server Kit components and Sugar Server Kit based solutions.
Using libsugaroid
It is useful for python code that tests, e.g., the school server internals.
See sugar-server integration tests for examples.
System testing scenarios
In this mode, the sugaroid application tries to behave as a regular host with sugar launched on it, including anti-thief features specific only for XO laptops.
Scenario files
Regular use involves writing scenarios—python scripts that need to be launched by the sugaroid
program, i.e., such files need to have headers (you need to have the path to the source sugaroid
file in the PATH
environment variable):
#!/bin/env sugaroid
Scenario files should have an access point, the function main
:
def main(context, args): pass
It will be launched by sugaroid
by passing an execution context as a libsugaroid.context.Context
object along with command-line arguments. The content of the main()
function is exactly the scenario in which sugaroid
should behave.
Actions
The building blocks of sugaroid scenarios are actions. Actions are objects of classes inherited from libsugaroid.context.Action
. Action classes represent one particular aspect of some sugar client behaviour, e.g., activation or backup.
A simple scenario looks like:
from libsugaroid.actions import Activation, Registration, Presence, Backup def main(context, args): context.call(Activation) context.call(Registration) context.call(Presence) context.call(Backup, tries=1)
Launch
The first command-line argument that scenario should receive is a nick of the sugar user. That nick will be used as a directory name in the --root
directory to store all data related to this nick. Thereafter, scenario should take a --server
command-line argument, with the launched sugar-server address, and a --lease_key
argument, with a path to the public key that was used to sign leases returned by sugar-server.
To simplify usage, serial number and UUID will be automatically generated basing on nick names. Thus, there is a fast way in which to let sugar-server know about leases for scenario nicks:
bc-make-lease `sugaroid id nick` days | sugar-server activation import_lease