5,705
edits
Changes
Platform Team/Server Kit/sugar-unit (view source)
Revision as of 14:53, 23 August 2011
, 14:53, 23 August 2011Created 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 ..."
== Summary ==
Library and application that mimic regular sugar users behaviour to help with testing [[Sugar Server Kit]] components.
== Using libsugaroid ==
Useful for python code that tests, e.g., the school server internals.
See sugar-server [http://git.sugarlabs.org/server/server/trees/master/tests/integration 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 {{Code|sugaroid}} program, i.e., such files need to have headers (you need to have path to source {{Code|sugaroid}} file in {{Code|PATH}} variable):
#!/bin/env sugaroid
Scenario files should have an access point, a function {{Code|main}}:
def main(context, args):
pass
it will be launched by {{Code|sugaroid}} with passing execution context as a {{Code|libsugaroid.context.Context}} object and command-line arguments. The content of {{Code|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 {{Code|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 {{Code|--root}} directory to store all data related to this nick. Besides, scenario should take {{Code|--server}} command-line argument with launched [[Sugar_Server_Kit/sugar-server|sugar-server]] address and {{Code|--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
== Getting involved ==
* [http://bugs.sugarlabs.org/newticket?component=sugar-server-kit Report] about bugs.
* Read the [http://git.sugarlabs.org/server/sugaroid/blobs/master/HACKING HACKING] file to know how to contribute by a code.
== Resources ==
* [http://git.sugarlabs.org/server/sugaroid Sources].
Library and application that mimic regular sugar users behaviour to help with testing [[Sugar Server Kit]] components.
== Using libsugaroid ==
Useful for python code that tests, e.g., the school server internals.
See sugar-server [http://git.sugarlabs.org/server/server/trees/master/tests/integration 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 {{Code|sugaroid}} program, i.e., such files need to have headers (you need to have path to source {{Code|sugaroid}} file in {{Code|PATH}} variable):
#!/bin/env sugaroid
Scenario files should have an access point, a function {{Code|main}}:
def main(context, args):
pass
it will be launched by {{Code|sugaroid}} with passing execution context as a {{Code|libsugaroid.context.Context}} object and command-line arguments. The content of {{Code|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 {{Code|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 {{Code|--root}} directory to store all data related to this nick. Besides, scenario should take {{Code|--server}} command-line argument with launched [[Sugar_Server_Kit/sugar-server|sugar-server]] address and {{Code|--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
== Getting involved ==
* [http://bugs.sugarlabs.org/newticket?component=sugar-server-kit Report] about bugs.
* Read the [http://git.sugarlabs.org/server/sugaroid/blobs/master/HACKING HACKING] file to know how to contribute by a code.
== Resources ==
* [http://git.sugarlabs.org/server/sugaroid Sources].