|
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|
|
|
<protocol name="weston_test">
|
|
|
|
|
|
|
|
<copyright>
|
|
|
|
Copyright © 2012 Intel Corporation
|
|
|
|
|
|
|
|
Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
copy of this software and associated documentation files (the "Software"),
|
|
|
|
to deal in the Software without restriction, including without limitation
|
|
|
|
the rights to use, copy, modify, merge, publish, distribute, sublicense,
|
|
|
|
and/or sell copies of the Software, and to permit persons to whom the
|
|
|
|
Software is furnished to do so, subject to the following conditions:
|
|
|
|
|
|
|
|
The above copyright notice and this permission notice (including the next
|
|
|
|
paragraph) shall be included in all copies or substantial portions of the
|
|
|
|
Software.
|
|
|
|
|
|
|
|
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
|
|
|
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
|
|
|
|
DEALINGS IN THE SOFTWARE.
|
|
|
|
</copyright>
|
|
|
|
|
|
|
|
<interface name="weston_test" version="1">
|
|
|
|
<description summary="weston internal testing">
|
|
|
|
Internal testing facilities for the weston compositor.
|
|
|
|
|
|
|
|
It can't be stressed enough that these should never ever be used
|
|
|
|
outside of running weston's tests. The weston-test.so module should
|
|
|
|
never be installed.
|
|
|
|
|
|
|
|
These requests may allow clients to do very bad things.
|
|
|
|
</description>
|
|
|
|
<request name="move_surface">
|
|
|
|
<arg name="surface" type="object" interface="wl_surface"/>
|
|
|
|
<arg name="x" type="int"/>
|
|
|
|
<arg name="y" type="int"/>
|
|
|
|
</request>
|
|
|
|
<request name="move_pointer">
|
|
|
|
<arg name="tv_sec_hi" type="uint"/>
|
|
|
|
<arg name="tv_sec_lo" type="uint"/>
|
|
|
|
<arg name="tv_nsec" type="uint"/>
|
|
|
|
<arg name="x" type="int"/>
|
|
|
|
<arg name="y" type="int"/>
|
|
|
|
</request>
|
|
|
|
<request name="send_button">
|
|
|
|
<arg name="tv_sec_hi" type="uint"/>
|
|
|
|
<arg name="tv_sec_lo" type="uint"/>
|
|
|
|
<arg name="tv_nsec" type="uint"/>
|
|
|
|
<arg name="button" type="int"/>
|
|
|
|
<arg name="state" type="uint"/>
|
|
|
|
</request>
|
|
|
|
<request name="send_axis">
|
|
|
|
<arg name="tv_sec_hi" type="uint"/>
|
|
|
|
<arg name="tv_sec_lo" type="uint"/>
|
|
|
|
<arg name="tv_nsec" type="uint"/>
|
|
|
|
<arg name="axis" type="uint"/>
|
|
|
|
<arg name="value" type="fixed"/>
|
|
|
|
</request>
|
|
|
|
<request name="activate_surface">
|
|
|
|
<arg name="surface" type="object" interface="wl_surface" allow-null="true"/>
|
|
|
|
</request>
|
|
|
|
<request name="send_key">
|
|
|
|
<arg name="tv_sec_hi" type="uint"/>
|
|
|
|
<arg name="tv_sec_lo" type="uint"/>
|
|
|
|
<arg name="tv_nsec" type="uint"/>
|
|
|
|
<arg name="key" type="uint"/>
|
|
|
|
<arg name="state" type="uint"/>
|
|
|
|
</request>
|
|
|
|
<request name="device_release">
|
|
|
|
<arg name="device" type="string"/>
|
|
|
|
</request>
|
|
|
|
<request name="device_add">
|
|
|
|
<arg name="device" type="string"/>
|
|
|
|
</request>
|
|
|
|
<event name="pointer_position">
|
|
|
|
<arg name="x" type="fixed"/>
|
|
|
|
<arg name="y" type="fixed"/>
|
|
|
|
</event>
|
|
|
|
<request name="send_touch">
|
|
|
|
<arg name="tv_sec_hi" type="uint"/>
|
|
|
|
<arg name="tv_sec_lo" type="uint"/>
|
|
|
|
<arg name="tv_nsec" type="uint"/>
|
|
|
|
<arg name="touch_id" type="int"/>
|
|
|
|
<arg name="x" type="fixed"/>
|
|
|
|
<arg name="y" type="fixed"/>
|
|
|
|
<arg name="touch_type" type="uint"/>
|
|
|
|
</request>
|
|
|
|
</interface>
|
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)
10 years ago
|
|
|
|
|
|
|
<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>
|