Difference between revisions of "Platform Team/Server Kit/sugar-unit"
m (→Launch) |
|||
Line 1: | Line 1: | ||
== Summary == | == Summary == | ||
− | + | '''{{Code|sugaroid}}''' is a library and application that mimics regular sugar client behaviour to help with testing [[Sugar Server Kit]] components and [[Sugar Server Kit]] based solutions. | |
== Using libsugaroid == | == Using libsugaroid == | ||
− | + | It is 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. | See sugar-server [http://git.sugarlabs.org/server/server/trees/master/tests/integration integration tests] for examples. | ||
Line 11: | Line 11: | ||
== System testing scenarios == | == 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. | + | 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 === | === Scenario files === | ||
− | + | Regular use involves writing scenarios—python scripts that need to be launched by the {{Code|sugaroid}} program, i.e., such files need to have headers (you need to have the path to the source {{Code|sugaroid}} file in the {{Code|PATH}} environment variable): | |
#!/bin/env sugaroid | #!/bin/env sugaroid | ||
Line 24: | Line 24: | ||
pass | pass | ||
− | + | It will be launched by {{Code|sugaroid}} by passing an execution context as a {{Code|libsugaroid.context.Context}} object along with command-line arguments. The content of the {{Code|main()}} function is exactly the scenario in which {{Code|sugaroid}} should behave. | |
=== Actions === | === Actions === | ||
− | The building blocks of sugaroid scenarios are actions. 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 building blocks of sugaroid scenarios are actions. Actions are objects of classes inherited from {{Code|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 | from libsugaroid.actions import Activation, Registration, Presence, Backup | ||
Line 42: | Line 42: | ||
=== Launch === | === Launch === | ||
− | The first command-line argument that scenario should | + | 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 {{Code|--root}} directory to store all data related to this nick. Thereafter, scenario should take a {{Code|--server}} command-line argument, with the launched [[Sugar_Server_Kit/sugar-server|sugar-server]] address, and a {{Code|--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 | + | 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 | bc-make-lease `sugaroid id ''nick''` ''days'' | sugar-server activation import_lease | ||
Line 50: | Line 50: | ||
== Getting involved == | == Getting involved == | ||
− | * [http://bugs.sugarlabs.org/newticket?component=sugar-server-kit Report] | + | * [http://bugs.sugarlabs.org/newticket?component=sugar-server-kit Report] on bugs. |
− | * Read the [http://git.sugarlabs.org/server/sugaroid/blobs/master/HACKING HACKING] file to know how to contribute | + | * Read the [http://git.sugarlabs.org/server/sugaroid/blobs/master/HACKING HACKING] file to know how to contribute with code. |
== Resources == | == Resources == | ||
* [http://git.sugarlabs.org/server/sugaroid Sources]. | * [http://git.sugarlabs.org/server/sugaroid Sources]. |
Revision as of 15:42, 23 August 2011
Summary
sugaroid
is a library and application that mimics regular sugar client behaviour to help 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