Difference between revisions of "Platform Team/Server Kit/sugar-unit"

From Sugar Labs
Jump to navigation Jump to search
Line 1: Line 1:
 
== Summary ==
 
== Summary ==
  
Library and application that mimic regular sugar clients behaviour to help with testing [[Sugar Server Kit]] components and [[Sugar Server Kit]] based solutions.
+
'''{{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 ==
  
Useful for python code that tests, e.g., the school server internals.
+
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 ===
  
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):
+
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}} 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.
+
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.
  
The simple scenario looks like:
+
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 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.
+
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 how to let sugar-server know about leases for scenario nicks:
+
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] about bugs.
+
* [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 by a code.
+
* 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

Getting involved

  • Report on bugs.
  • Read the HACKING file to know how to contribute with code.

Resources