weston/tests/ivi_layout-test.c

235 lines
5.8 KiB
C
Raw Normal View History

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)
2015-03-25 10:50:31 +00:00
/*
* 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)
2015-03-25 10:50:31 +00:00
*
* 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)
2015-03-25 10:50:31 +00:00
*/
#include "config.h"
#include <stdio.h>
#include <string.h>
#include "shared/helpers.h"
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)
2015-03-25 10:50:31 +00:00
#include "weston-test-client-helper.h"
#include "ivi-application-client-protocol.h"
#include "ivi-test.h"
struct runner {
struct client *client;
struct weston_test_runner *test_runner;
int done;
};
static void
runner_finished_handler(void *data, struct weston_test_runner *test_runner)
{
struct runner *runner = data;
runner->done = 1;
}
static const struct weston_test_runner_listener test_runner_listener = {
runner_finished_handler
};
static struct runner *
client_create_runner(struct client *client)
{
struct runner *runner;
struct global *g;
struct global *global_runner = NULL;
runner = xzalloc(sizeof(*runner));
runner->client = client;
wl_list_for_each(g, &client->global_list, link) {
if (strcmp(g->interface, "weston_test_runner"))
continue;
if (global_runner)
assert(0 && "multiple weston_test_runner objects");
global_runner = g;
}
assert(global_runner && "no weston_test_runner found");
assert(global_runner->version == 1);
runner->test_runner = wl_registry_bind(client->wl_registry,
global_runner->name,
&weston_test_runner_interface,
1);
assert(runner->test_runner);
weston_test_runner_add_listener(runner->test_runner,
&test_runner_listener, runner);
return runner;
}
static void
runner_destroy(struct runner *runner)
{
weston_test_runner_destroy(runner->test_runner);
client_roundtrip(runner->client);
free(runner);
}
static void
runner_run(struct runner *runner, const char *test_name)
{
fprintf(stderr, "weston_test_runner.run(\"%s\")\n", test_name);
runner->done = 0;
weston_test_runner_run(runner->test_runner, test_name);
while (!runner->done) {
if (wl_display_dispatch(runner->client->wl_display) < 0)
assert(0 && "runner wait");
}
}
static struct ivi_application *
get_ivi_application(struct client *client)
{
struct global *g;
struct global *global_iviapp = NULL;
static struct ivi_application *iviapp;
if (iviapp)
return iviapp;
wl_list_for_each(g, &client->global_list, link) {
if (strcmp(g->interface, "ivi_application"))
continue;
if (global_iviapp)
assert(0 && "multiple ivi_application objects");
global_iviapp = g;
}
assert(global_iviapp && "no ivi_application found");
assert(global_iviapp->version == 1);
iviapp = wl_registry_bind(client->wl_registry, global_iviapp->name,
&ivi_application_interface, 1);
assert(iviapp);
return iviapp;
}
struct ivi_window {
struct wl_surface *wl_surface;
struct ivi_surface *ivi_surface;
uint32_t ivi_id;
};
static struct ivi_window *
client_create_ivi_window(struct client *client, uint32_t ivi_id)
{
struct ivi_application *iviapp;
struct ivi_window *wnd;
iviapp = get_ivi_application(client);
wnd = xzalloc(sizeof(*wnd));
wnd->wl_surface = wl_compositor_create_surface(client->wl_compositor);
wnd->ivi_surface = ivi_application_surface_create(iviapp, ivi_id,
wnd->wl_surface);
wnd->ivi_id = ivi_id;
return wnd;
}
static void
ivi_window_destroy(struct ivi_window *wnd)
{
ivi_surface_destroy(wnd->ivi_surface);
wl_surface_destroy(wnd->wl_surface);
free(wnd);
}
/******************************** tests ********************************/
/*
* This is a test program, launched by ivi_layout-test-plugin.c. Each TEST()
* is forked and exec'd as usual with the weston-test-runner framework.
*
* These tests make use of weston_test_runner global interface exposed by
* ivi_layout-test-plugin.c. This allows these tests to trigger compositor-side
* checks.
*
* See ivi_layout-test-plugin.c for further details.
*/
/**
* RUNNER_TEST() names are defined in ivi_layout-test-plugin.c.
* Each RUNNER_TEST name listed here uses the same simple initial client setup.
*/
const char * const basic_test_names[] = {
"surface_visibility",
"surface_opacity",
};
TEST_P(ivi_layout_runner, basic_test_names)
{
/* an element from basic_test_names */
const char * const *test_name = data;
struct client *client;
struct runner *runner;
struct ivi_window *wnd;
client = create_client();
runner = client_create_runner(client);
wnd = client_create_ivi_window(client, IVI_TEST_SURFACE_ID(0));
runner_run(runner, *test_name);
ivi_window_destroy(wnd);
runner_destroy(runner);
}
TEST(ivi_layout_surface_create)
{
struct client *client;
struct runner *runner;
struct ivi_window *winds[2];
client = create_client();
runner = client_create_runner(client);
winds[0] = client_create_ivi_window(client, IVI_TEST_SURFACE_ID(0));
winds[1] = client_create_ivi_window(client, IVI_TEST_SURFACE_ID(1));
runner_run(runner, "surface_create_p1");
ivi_window_destroy(winds[0]);
runner_run(runner, "surface_create_p2");
ivi_window_destroy(winds[1]);
runner_destroy(runner);
}