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

From Sugar Labs
Jump to navigation Jump to search
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
== Summary ==
 
== Summary ==
  
−
The project is intended to:
+
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.
  
−
* Provide high level code, based on Python unittest library, to simplify Sugar related development;
+
== Library ==
−
* Emulate regular Sugar client behaviour to help, e.g., 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.
 
It is useful for python code that tests, e.g., the school server internals.
Line 14: Line 11:
 
== 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
 
−
 
 
−
Scenario files should have an access point, the function {{Code|main}}:
 
  
−
  def main(context, args):
+
  #!/bin/env sugar-unit
−
    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.
+
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 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.
  
 
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
 
   
 
   
−
  def main(context, args):
+
  class Test(tests.Case):
−
    context.call(Activation)
+
−
    context.call(Registration)
+
    def test_XO_walkthrough(self):
−
    context.call(Presence)
+
        self.assertAction(actions.Activation)
−
    context.call(Backup, tries=1)
+
        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 ===
  
−
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.
+
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, 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:
+
'''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 ==
 
== Getting involved ==
Line 58: Line 73:
 
== Resources ==
 
== Resources ==
  
−
* [http://git.sugarlabs.org/sdk/sugar-unit Sources].
+
* [http://git.sugarlabs.org/server/unit Sources].

Latest revision as of 04: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

Retrieved from "https://wiki.sugarlabs.org/index.php?title=Platform_Team/Server_Kit/sugar-unit&oldid=76683"