Platform Team/Server Kit/sugar-unit: Difference between revisions
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