tests/testing

   1 Automotive Message Broker testing
   2
   3 Abstract:
   4
   5 This document outlines steps that should be taken in order to test Automotive Message Broker (AMB) functionality.
   6
   7 Contents:
   8
   9 I. Internal testing
  10 II. DBus API testing
  11 III. Performance testing
  12
  13
  14 Internal testing
  15
  16 AMB performs internal testing of core functionality via the "test" plugin[1].  This plugin tests
  17 AbstractRoutingEngine methods.  If a test failes, ambd will abort.  This plugins also prints out the total
  18 property capabilities of AMB.  This is useful for verifying the addition of core properties to AMB's capabilities.
  19 To run the test plugin, simply run ambd with the following example configuration[2]:
  20
  21 ambd -c testsourceconfig -d5
  22
  23 Debug level 5 is usually enough to get most debug or log information from ambd.
  24
  25 References:
  26 [1] - Test plugin: https://github.com/otcshare/automotive-message-broker/blob/master/plugins/testplugin/README
  27 [2] - Test plugin config: https://github.com/otcshare/automotive-message-broker/blob/master/examples/testsourceconfig
  28
  29 DBus API testing
  30
  31 AMB exposes a complex API over DBus[1].  This document will only lightly touch on the organization of the API for
  32 testing purposes.  For a information, please refer to the AMB DBus API documentation.  The API has two general
  33 interfaces: "Manager", and "DataType".  DataType refers to a particular type of vehicle data such as "VehicleSpeed".
  34 The easiest way to test the AMB DBus API is to run the example dbus config[3]:
  35
  36 ambd -c dbusconfig -d5
  37
  38 Manager testing
  39
  40 The Manager interfaces[2] is located in "/" with the interface "org.automotive.Manager".  Manager is used to create
  41 and find DataTypes.  It has the following methods:
  42
  43 List
  44 FindObject
  45 ZonesForObjectName
  46 FindObjectForSourceZone
  47 FindObjectForZone
  48 SourcesForObjectName
  49
  50 Please refer to the Manager documentation for specific explaination on what these methods do.
  51
  52 To test these methods, dbus-send, which comes with most linux distros can be used.  The following is the general
  53 pattern:
  54
  55 dbus-send --system --print-reply --dest=org.automotive.message.broker / org.automotive.Manager.{METHOD_NAME} ...
  56
  57 To test the "List" method:
  58
  59 dbus-send --system --print-reply --dest=org.automotive.message.broker / org.automotive.Manager.List
  60
  61 This should return a list of supported DataTypes that can be used to create and find object paths representing that
  62 type.
  63
  64 To test the "FindObject" method:
  65
  66 dbus-send --system --print-reply --dest=org.automotive.message.broker / org.automotive.Manager.FindObject string:VehicleSpeed
  67
  68 This should return a list of objects that provide the data type "VehicleSpeed"
  69
  70 The other methods follow the same pattern.  See the documentation for the arguments and return values.
  71
  72 Because of the dynamic nature of the API (objects may not exist until Manager creates them), simple tools like dbus-send, gdbus or qdbus will not suffice for most operations.  To compensate for these lack of tools, AMB includes several helper scripts:
  73
  74 amb-get
  75 amb-set
  76 amb-get-history
  77 amb-listen
  78
  79 These scripts can be used to get values of objects, set properties on objects, get historic/logged data and listen
  80 for changes to objects.  For usage, please see [command] -h.  For example: "amb-get -h".
  81
  82 References:
  83 [1] - DBus API documentation: https://github.com/otcshare/automotive-message-broker/blob/master/docs/README
  84 [2] - Manager interface documentation: https://github.com/otcshare/automotive-message-broker/blob/master/docs/manager.txt
  85 [3] - DBus config: https://github.com/otcshare/automotive-message-broker/blob/master/examples/dbusconfig
  86
  87 Performance Testing
  88
  89 In addition to general profiling tools, AMB comes with a few ways you can measure performance.  When running ambd
  90 with the -d1 option, you can see how many property updates are being generated per second and how many are actually
  91 being fired because a plugin is subscribed to that property.  Coupling this with CPU usage measuring tools can help
  92 with measuring performance.
  93
  94