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

From Sugar Labs
Jump to navigation Jump to search
(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 15: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

Getting involved

  • Report about bugs.
  • Read the HACKING file to know how to contribute by a code.

Resources