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

Latest revision as of 05:48, 21 March 2012

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.

Library

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 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

Regular use involves writing scenarios—python scripts that need to be launched by the sugar-unit program, i.e., such files need to have headers (you need to have the path to the source sugar-unit file in the PATH environment variable):

#!/bin/env sugar-unit

Scenario files should classes inherited from sugar_unit.tests.Case that are regular unittest.TestCase classes.

Actions

The building blocks of sugar-unit scenarios are actions. Actions are objects of classes inherited from 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:

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

Useful command-line arguments.

nick

While working, sugar-unit will behave on behalf of only one Sugar user. By default, user's nick is test, but it might be changed using the --nick command-line argument. The XO serial number and UUID will be calculated basing on nickname. Default nickname is also hardcoded in sugar-server sources, so, sugar-server will always have a lease for this nick. For non-default nicknames, the corresponding leases need to be registered in sugar-server, getting SN and UUID from sugar-unit id output.

profile-dir

sugar-unit will create a directory for Sugar profile, i.e., an analog of profile directories in ~/.sugar. By default, profile directory will be created in the current one using nickname as a directory name. It might be changed using the --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 (which sugar-server uses for default lease) comes with sugar-unit sources. For non-default leases, use the --lease-key command-line argument to specify the key path.

api-url

By default, sugar-unit will look for default, hardcoded in Sugar Shell sources, API url, http://schoolserver:8000. But, it is possible to specify any other, using the --api-url command-line argument.

Getting involved

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

Resources

Sources.

@@ Line 1: / Line 1: @@
 == Summary ==
-Library and application that mimic regular sugar clients behaviour to help 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 ==
-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.
@@ Line 11: / Line 11: @@
 == 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 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 ===
-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&mdash;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.
- 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 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 sugar-unit 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.
-The 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'
- def main(context, args):
+        self.assertAction(actions.Presence)
-     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.
+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 the {{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 always 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 created in the current one using nickname as a directory name. It might be changed using the {{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 (which 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.
-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:
+'''api-url'''
- bc-make-lease `sugaroid id ''nick''` ''days'' | sugar-server activation import_lease
+:: By default, sugar-unit will look for default, hardcoded in Sugar Shell sources, API url, {{Code|http://schoolserver:8000}}. But, it is possible to specify any other, using the {{Code|--api-url}} command-line argument.
 == 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 ==
-* [http://git.sugarlabs.org/server/sugaroid Sources].
+* [http://git.sugarlabs.org/server/unit Sources].