Difference between revisions of "Platform Team/Server Kit/sugar-unit"
(Created page with "== Summary == Library and application that mimic regular sugar users behaviour to help with testing Sugar Server Kit components. == Using libsugaroid == Useful for python ...") |
|||
Line 1: | Line 1: | ||
== Summary == | == Summary == | ||
− | Library and application that mimic regular sugar users behaviour to help with testing [[Sugar Server Kit]] components. | + | Library and application that mimic regular sugar users behaviour to help with testing [[Sugar Server Kit]] components and [[Sugar Server Kit]] based solutions. |
== Using libsugaroid == | == Using libsugaroid == |
Revision as of 14:55, 23 August 2011
Summary
Library and application that mimic regular sugar users behaviour to help with testing Sugar Server Kit components and Sugar Server Kit based solutions.
Using libsugaroid
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, 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
The regular way is writing scenarios, python scripts that need to be launched by sugaroid
program, i.e., such files need to have headers (you need to have path to source sugaroid
file in PATH
variable):
#!/bin/env sugaroid
Scenario files should have an access point, a function main
:
def main(context, args): pass
it will be launched by sugaroid
with passing execution context as a libsugaroid.context.Context
object and command-line arguments. The content of main()
function is exactly the scenario how sugaroid should behave.
Actions
The building block of sugaroid scenarios are actions. These actions are objects of classes inherited from libsugaroid.context.Action
. Action classes represent one particular aspect of sugar client behaviour, e.g., activation or backup.
The 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 get is a nick of sugar user. That nick will be used as a directory name in --root
directory to store all data related to this nick. Besides, scenario should take --server
command-line argument with launched sugar-server address and --lease_key
with a path to public key that was used to sign leases returned by sugar-server.
To simplify usage, anti-thief metadata like serial number and UUID will be automatically generated basing on nick names. Thus, there is fast way how to let sugar-server know about leases for scenario nicks:
bc-make-lease `sugaroid id nick` days | sugar-server activation import_lease