You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
weston/tests/ivi-test.h

38 lines
1.5 KiB

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
/*
* Copyright © 2015 Collabora, Ltd.
*
* 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:
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
*
* 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.
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
*/
#ifndef IVI_TEST_H
#define IVI_TEST_H
/*
* IVI_TEST_SURFACE_ID_BASE is an arbitrary number picked for the
* IVI tests. The only requirement is that it does not clash with
* any other ivi-id range used in Weston.
*/
#define IVI_TEST_SURFACE_ID_BASE 0xffc01200
#define IVI_TEST_SURFACE_ID(i) (IVI_TEST_SURFACE_ID_BASE + i)
#endif /* IVI_TEST_H */