tests: ivi_layout test infrastructure

Testing the ivi_layout API requires two things:
- the tests must be written as a controller module to access the API
- the tests need a helper client to create some objects that can then be
  managed via the API

This patch adds all the infrastructure and two different kinds of
example tests.

Internal ivi-shell (ivi_layout) API tests are listed as ivi-*.la files
in TESTS in Makefile.am. Weston-tests-env detects these, and runs Weston
with ivi-shell, and loads the given module as a controller module, not
as a normal plugin.

The test controller module ivi-*.la will launch a helper client. For
ivi-layout-test.la the helper client is ivi-layout.ivi.

The helper client uses the weston-test-runner framework to fork and exec
each TEST with a fresh connection to the compositor.

The actual test is triggered by the weston_test_runner protocol
interface, a new addition to weston-test.xml. The helper client uses
weston_test_runner to trigger a test, and the server side of the
interface is implemented by the test controller module
(ivi-layout-test.la).

The server side of weston_test_runner uses the same trick as
weston-test-runner.h to gather a list of defined tests. A test is
defined with the RUNNER_TEST macro.

If a test defined by RUNNER_TEST succeeds, an event is sent to the
helper client that it can continue (or exit). If a test fails, a fatal
protocol error is sent to the helper client.

Once the helper client has iterated over all of its tests, it signals
the batch success/failure via process exit code. That is cought in the
test controller module, and forwarded as Weston's exit code.

In summary: each ivi_layout test is a combination of a client side
helper/setup and server side actual tests.

v2: Load weston-test.so, because create_client() needs it.

v3: add a comment about IVI_TEST_SURFACE_ID_BASE.

v4: Rebased to upstream weston-tests-env changes.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com> (v2)

1 files changed, 35 insertions, 0 deletions

diff --git a/protocol/weston-test.xml b/protocol/weston-test.xml
index 538d6680..643a0c7c 100644
--- a/protocol/weston-test.xml
+++ b/protocol/weston-test.xml
@@ -74,4 +74,39 @@
       <arg name="n" type="uint"/>
     </event>
   </interface>
+
+  <interface name="weston_test_runner" version="1">
+    <description summary="weston internal testing">
+      This is a global singleton interface for Weston internal tests.
+
+      This interface allows a test client to trigger compositor-side
+      test procedures. This is useful for cases, where the actual tests
+      are in compositor plugins, but they also require the presence of
+      a particular client.
+
+      This interface is implemented by the compositor plugins containing
+      the testing code.
+
+      A test client starts a test with the "run" request. It must not send
+      another "run" request until receiving the "finished" event. If the
+      compositor-side test succeeds, the "finished" event is sent. If the
+      compositor-side test fails, the compositor should send the protocol
+      error "test_failed", but it may also exit with an error (e.g. SEGV).
+
+      Unknown test name will raise "unknown_test" protocol error.
+    </description>
+
+    <enum name="error">
+      <entry name="test_failed" value="0" summary="compositor test failed"/>
+      <entry name="unknown_test" value="1" summary="unrecognized test name"/>
+    </enum>
+
+    <request name="destroy" type="destructor"/>
+
+    <request name="run">
+      <arg name="test_name" type="string"/>
+    </request>
+
+    <event name="finished"/>
+  </interface>
 </protocol>