5,705
edits
Changes
Jump to navigation
Jump to search
Line 3:
Line 3: − + Line 11:
Line 11: − + − + − + − + − − def main(context, args): − 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. − + − + + + + + + + + + + + + + + + + − def main(context, args):+ − context.call(Activation) − context.call(Registration) − context.call(Presence) − context.call(Backup, tries=1) − 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 in which to let sugar-server know about leases for scenario nicks:+ − bc-make-lease `sugaroid id ''nick''` ''days'' | sugar-server activation import_lease+
Platform Team/Server Kit/sugar-unit (view source)
Revision as of 17:55, 30 November 2011
, 17:55, 30 November 2011no edit summary
The project is intended to emulate regular Sugar client behaviour to help, e.g., with testing [[Sugar Server Kit]] components and [[Sugar Server Kit]] based solutions.
The project is intended to emulate regular Sugar client behaviour to help, e.g., with testing [[Sugar Server Kit]] components and [[Sugar Server Kit]] based solutions.
== Using libsugaroid ==
== Library ==
It is 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.
== System testing scenarios ==
== 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.
In this mode, the sugar-unit 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):
Regular use involves writing scenarios—python scripts that need to be launched by the {{Code|sugar-unit}} program, i.e., such files need to have headers (you need to have the path to the source {{Code|sugar-unit}} file in the {{Code|PATH}} environment variable):
#!/bin/env sugaroid
#!/bin/env sugar-unit
Scenario files should have an access point, the function {{Code|main}}:
Scenario files should classes inherited from {{Code|sugar_unit.tests.Case}} that are regular {{Code|unittest.TestCase}} classes.
=== 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 some sugar client behaviour, e.g., activation or backup.
The building blocks of sugaroid scenarios are actions. Actions are objects of classes inherited from {{Code|sugar_unit.context.Action}}. Action classes represent one particular aspect of some sugar client behaviour, e.g., activation or backup.
A simple scenario looks like:
A simple scenario looks like:
from libsugaroid.actions import Activation, Registration, Presence, Backup
import os
from sugar_unit import tests, actions
class Test(tests.Case):
def test_XO_walkthrough(self):
self.assertAction(actions.Activation)
self.assertAction(actions.Registration, force=True)
ds_path = self.bot.store('foo', 'bar')
self.assertAction(actions.Backup)
os.unlink(ds_path)
self.assertAction(actions.Restore)
assert exists(ds_path)
assert file(ds_path).read() == 'bar'
self.assertAction(actions.Presence)
=== Launch ===
=== Launch ===
Useful command-line arguments.
'''nick'''
:: While working, sugar-unit will behave on behalf of only one Sugar user. By default, user's nick is {{Code|test}}, but it might be changed using {{Code|--nick}} command-line argument. The XO serial number and UUID will be calculated basing on nickname. Default nickname is also hardcoded in [[Sugar_Server_Kit/sugar-server|sugar-server]] sources, so, sugar-server will all time have a lease for this nick. For non-default nicknames, the corresponding leases need to be [[Sugar_Server_Kit/sugar-server#activation|registered]] in sugar-server getting SN and UUID from {{Code|sugar-unit id}} output.
'''profile-dir'''
:: sugar-unit will create a directory for Sugar profile, i.e., an analog of profile directories in {{Code|~/.sugar}}. By default, profile directory will be create in the current one using nickname as a directory name. It might be changed using {{Code|--profile-dir}} command-line argument.
'''lease-key'''
:: To verify leases gotten from the sugar-server, sugar-unit should know the lease public key, the default one (that sugar-server uses for default lease) comes with sugar-unit sources. For non-default leases, use the {{Code|--lease-key}} command-line argument to specify the key path.
'''api-url'''
:: By default, sugar-unit will look for default, for sugar-server, server API url, {{Code|localhost:8000}}. But it is possible to specify any other, using the {{Code|--api-url}} command-line argument.
== Getting involved ==
== Getting involved ==