mirrors/weston
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
37a0544edf
weston/tests/ivi-layout-test-client.c

532 lines
14 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 13:50:31 +03:00
/*
* Copyright © 2015 Collabora, Ltd.
*
tests: Update boilerplate from MIT X11 license to MIT Expat license
2015-06-12 01:39:40 +03:00
* 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 13:50:31 +03:00
*
tests: Update boilerplate from MIT X11 license to MIT Expat license
2015-06-12 01:39:40 +03: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 13:50:31 +03:00
*/
#include "config.h"
include stdint.h for int32_t/uint32_t Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com> Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
2016-07-19 14:16:27 +03:00
#include <stdint.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 13:50:31 +03:00
#include <stdio.h>
#include <string.h>
Moved helper macro to a discrete include file. To help reduce code duplication and also 'kitchen-sink' includes the ARRAY_LENGTH macro was moved to a stand-alone file and referenced from the sources consuming it. Other macros will be added in subsequent passes. Signed-off-by: Jon A. Cruz <jonc@osg.samsung.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
2015-06-16 01:37:08 +03:00
#include "shared/helpers.h"
clients & tests: Unify multiple definitions of x*alloc and related functions Direct fail_on_null calls now produce output like: [weston-info] clients/weston-info.c:714: out of memory xmalloc, et al produce output on failure like: [weston-info] out of memory (-1) Signed-off-by: Bryce Harrington <bryce@osg.samsung.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
2016-03-17 00:15:18 +03:00
#include "shared/xalloc.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 13:50:31 +03:00
#include "weston-test-client-helper.h"
#include "ivi-application-client-protocol.h"
#include "ivi-test.h"
tests: migrate ivi-layout-test The ivi-layout-test comprises of two halves: the client and the plugin. This migrates the test to the new test harness. In the old harness, the plugin was built as the test in meson.build and it fork & exec'd the client part. In the new harness client tests start from the client program which sets up the compositor in-process, so now the client is built as the test in meson.build and the plugin is just an additional file. Therefore there is not need for the plugin for fork & exec anything anymore, so all that code is removed. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-11 16:30:07 +03:00
#include "weston-test-fixture-compositor.h"
static enum test_result_code
fixture_setup(struct weston_test_harness *harness)
{
struct compositor_setup setup;
compositor_setup_defaults(&setup);
setup.shell = SHELL_IVI;
setup.extra_module = "test-ivi-layout.so";
return weston_test_harness_execute_as_client(harness, &setup);
}
DECLARE_FIXTURE_SETUP(fixture_setup);
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 13:50:31 +03:00
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)
{
tests: replace fprintf() with testlog() When we move on to TAP, stdout will be reserved for TAP and stderr is for free chatter. Set up an example that tests should use testlog() instead of fprintf or printf to chat in the right place. Most statements were already printing to stderr, so this just makes then a little shorter. There are also some statements that printed to stdout and are now corrected. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-06 16:59:33 +03:00
testlog("weston_test_runner.run(\"%s\")\n", test_name);
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 13:50:31 +03:00
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;
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
struct ivi_application *iviapp;
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 13:50:31 +03:00
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 *
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
client_create_ivi_window(struct client *client,
struct ivi_application *iviapp,
uint32_t ivi_id)
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 13:50:31 +03:00
{
struct ivi_window *wnd;
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 ********************************/
/*
* These tests make use of weston_test_runner global interface exposed by
tests: Reshuffle IVI layout tests Rename the IVI tests to be more consistent with the others, and invert the naming of plugin/client to make it slightly more clear what's going to happen. Handle the renaming by using wet_get_binary_path to rewrite the local binaries. As a side-effect, weston.ini ivi-shell-user-interface no longer needs to be given as an absolute path. Signed-off-by: Daniel Stone <daniels@collabora.com> v2: Call ivi-layout.ivi as ivi-layout-test-client.ivi to keep the same name in both the file and the lookup, so that the module map does not need to change the name. Update code comments to reflect the new names. Rename ivi_layout-test-plugin.c to ivi-layout-test-plugin.c. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Emre Ucan <eucan@de.adit-jv.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
2016-11-28 18:54:06 +03:00
* ivi-layout-test-plugin.c. This allows these tests to trigger compositor-side
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 13:50:31 +03:00
* checks.
*
tests: Reshuffle IVI layout tests Rename the IVI tests to be more consistent with the others, and invert the naming of plugin/client to make it slightly more clear what's going to happen. Handle the renaming by using wet_get_binary_path to rewrite the local binaries. As a side-effect, weston.ini ivi-shell-user-interface no longer needs to be given as an absolute path. Signed-off-by: Daniel Stone <daniels@collabora.com> v2: Call ivi-layout.ivi as ivi-layout-test-client.ivi to keep the same name in both the file and the lookup, so that the module map does not need to change the name. Update code comments to reflect the new names. Rename ivi_layout-test-plugin.c to ivi-layout-test-plugin.c. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Emre Ucan <eucan@de.adit-jv.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
2016-11-28 18:54:06 +03:00
* See ivi-layout-test-plugin.c for further details.
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 13:50:31 +03:00
*/
/**
tests: Reshuffle IVI layout tests Rename the IVI tests to be more consistent with the others, and invert the naming of plugin/client to make it slightly more clear what's going to happen. Handle the renaming by using wet_get_binary_path to rewrite the local binaries. As a side-effect, weston.ini ivi-shell-user-interface no longer needs to be given as an absolute path. Signed-off-by: Daniel Stone <daniels@collabora.com> v2: Call ivi-layout.ivi as ivi-layout-test-client.ivi to keep the same name in both the file and the lookup, so that the module map does not need to change the name. Update code comments to reflect the new names. Rename ivi_layout-test-plugin.c to ivi-layout-test-plugin.c. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Emre Ucan <eucan@de.adit-jv.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
2016-11-28 18:54:06 +03:00
* RUNNER_TEST() names are defined in ivi-layout-test-plugin.c.
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 13:50:31 +03:00
* Each RUNNER_TEST name listed here uses the same simple initial client setup.
*/
const char * const basic_test_names[] = {
"surface_visibility",
"surface_opacity",
tests: test set for ivi-surface normal use case with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested for ivi-surface - orientation - dimension - position - destination rectangle - source rectangle Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:33:17 +03:00
"surface_dimension",
"surface_position",
"surface_destination_rectangle",
"surface_source_rectangle",
tests: test set for ivi-surface bad condition with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - ivi_layout_runner with basic_test_names[] - surface with bad opacity - destroy ivi/wl_surface and call get_surface - commit_changes_after_properties_set_surface_destroy with surface_property_commit_changes_test_names[] - call set_visibility, destroy ivi-surface, and commit_changes - call set_opacity, destroy ivi-surface, and commit_changes - call set_orientation, destroy ivi-surface, and commit_changes - call set_dimension, destroy ivi-surface, and commit_changes - call set_position, destroy ivi-surface, and commit_changes - call set_source_rectangle, destroy ivi-surface, and commit_changes - call set_destination_rectangle, destroy ivi-surface, and commit_changes Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:33:26 +03:00
"surface_bad_opacity",
tests: test set for ivi-shell notification normal use case with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - notification of adding ivi-surface - notification of ivi-surface configure - notification of creating ivi-surface - notification of removing ivi-surface Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:35:58 +03:00
"surface_properties_changed_notification",
tests: test set for ivi-shell notification in bad condition with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - add notfication of ivi-surface with bad condition Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:36:21 +03:00
"surface_bad_properties_changed_notification",
ivi-shell: implement surface_on_many_layer test A surface can be added to many layers. This test is implemented to test this use-case and the correct behaviour of get_layers_under_surface API. Signed-off-by: Emre Ucan <eucan@de.adit-jv.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
2016-06-07 12:40:21 +03:00
"surface_on_many_layer",
tests: test set for ivi-surface bad condition with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - ivi_layout_runner with basic_test_names[] - surface with bad opacity - destroy ivi/wl_surface and call get_surface - commit_changes_after_properties_set_surface_destroy with surface_property_commit_changes_test_names[] - call set_visibility, destroy ivi-surface, and commit_changes - call set_opacity, destroy ivi-surface, and commit_changes - call set_orientation, destroy ivi-surface, and commit_changes - call set_dimension, destroy ivi-surface, and commit_changes - call set_position, destroy ivi-surface, and commit_changes - call set_source_rectangle, destroy ivi-surface, and commit_changes - call set_destination_rectangle, destroy ivi-surface, and commit_changes Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:33:26 +03:00
};
const char * const surface_property_commit_changes_test_names[] = {
"commit_changes_after_visibility_set_surface_destroy",
"commit_changes_after_opacity_set_surface_destroy",
"commit_changes_after_source_rectangle_set_surface_destroy",
"commit_changes_after_destination_rectangle_set_surface_destroy",
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 13:50:31 +03:00
};
tests: test set for ivi-layer normal use case with helper client These test are implemented on test suite framework, which provides helper client. Following features are tested, - render order of ivi-surfaces on ivi-layer Signed-off-by: Nobuhiko Tanibata <nobuhiko_tanibata@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:34:09 +03:00
const char * const render_order_test_names[] = {
"layer_render_order",
tests: test set for ivi-layer bad condition with helper-client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - bad render order of ivi-surface on ivi-layer - call commitchanges after a ivi_surface in render order is destoryed Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:34:42 +03:00
"layer_bad_render_order",
ivi-shell: add layer_add_surfaces test Test adds 3 surfaces in a layer's render order list. First, it adds in the order which surfaces are created. Later, test cleans the render order list, and adds surfaces in reverse order. Signed-off-by: Emre Ucan <eucan@de.adit-jv.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
2017-01-18 18:25:35 +03:00
"layer_add_surfaces",
tests: test set for ivi-layer normal use case with helper client These test are implemented on test suite framework, which provides helper client. Following features are tested, - render order of ivi-surfaces on ivi-layer Signed-off-by: Nobuhiko Tanibata <nobuhiko_tanibata@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:34:09 +03:00
};
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 13:50:31 +03:00
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;
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
struct ivi_application *iviapp;
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 13:50:31 +03:00
struct ivi_window *wnd;
client = create_client();
runner = client_create_runner(client);
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
iviapp = get_ivi_application(client);
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 13:50:31 +03:00
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
wnd = client_create_ivi_window(client, iviapp, IVI_TEST_SURFACE_ID(0));
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 13:50:31 +03:00
runner_run(runner, *test_name);
ivi_window_destroy(wnd);
runner_destroy(runner);
tests: fix leaks in ivi-layout-test-client Everything here was systematically leaking client and iviapp. Discovered by ASan on ./tests/test-ivi-layout-client Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2021-06-14 14:38:04 +03:00
ivi_application_destroy(iviapp);
client_destroy(client);
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 13:50:31 +03:00
}
TEST(ivi_layout_surface_create)
{
struct client *client;
struct runner *runner;
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
struct ivi_application *iviapp;
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 13:50:31 +03:00
struct ivi_window *winds[2];
client = create_client();
runner = client_create_runner(client);
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
iviapp = get_ivi_application(client);
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 13:50:31 +03:00
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
winds[0] = client_create_ivi_window(client, iviapp,
IVI_TEST_SURFACE_ID(0));
winds[1] = client_create_ivi_window(client, iviapp,
IVI_TEST_SURFACE_ID(1));
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 13:50:31 +03:00
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);
tests: fix leaks in ivi-layout-test-client Everything here was systematically leaking client and iviapp. Discovered by ASan on ./tests/test-ivi-layout-client Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2021-06-14 14:38:04 +03:00
ivi_application_destroy(iviapp);
client_destroy(client);
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 13:50:31 +03:00
}
tests: test set for ivi-surface bad condition with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - ivi_layout_runner with basic_test_names[] - surface with bad opacity - destroy ivi/wl_surface and call get_surface - commit_changes_after_properties_set_surface_destroy with surface_property_commit_changes_test_names[] - call set_visibility, destroy ivi-surface, and commit_changes - call set_opacity, destroy ivi-surface, and commit_changes - call set_orientation, destroy ivi-surface, and commit_changes - call set_dimension, destroy ivi-surface, and commit_changes - call set_position, destroy ivi-surface, and commit_changes - call set_source_rectangle, destroy ivi-surface, and commit_changes - call set_destination_rectangle, destroy ivi-surface, and commit_changes Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:33:26 +03:00
TEST_P(commit_changes_after_properties_set_surface_destroy, surface_property_commit_changes_test_names)
{
/* an element from surface_property_commit_changes_test_names */
const char * const *test_name = data;
struct client *client;
struct runner *runner;
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
struct ivi_application *iviapp;
tests: test set for ivi-surface bad condition with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - ivi_layout_runner with basic_test_names[] - surface with bad opacity - destroy ivi/wl_surface and call get_surface - commit_changes_after_properties_set_surface_destroy with surface_property_commit_changes_test_names[] - call set_visibility, destroy ivi-surface, and commit_changes - call set_opacity, destroy ivi-surface, and commit_changes - call set_orientation, destroy ivi-surface, and commit_changes - call set_dimension, destroy ivi-surface, and commit_changes - call set_position, destroy ivi-surface, and commit_changes - call set_source_rectangle, destroy ivi-surface, and commit_changes - call set_destination_rectangle, destroy ivi-surface, and commit_changes Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:33:26 +03:00
struct ivi_window *wnd;
client = create_client();
runner = client_create_runner(client);
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
iviapp = get_ivi_application(client);
tests: test set for ivi-surface bad condition with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - ivi_layout_runner with basic_test_names[] - surface with bad opacity - destroy ivi/wl_surface and call get_surface - commit_changes_after_properties_set_surface_destroy with surface_property_commit_changes_test_names[] - call set_visibility, destroy ivi-surface, and commit_changes - call set_opacity, destroy ivi-surface, and commit_changes - call set_orientation, destroy ivi-surface, and commit_changes - call set_dimension, destroy ivi-surface, and commit_changes - call set_position, destroy ivi-surface, and commit_changes - call set_source_rectangle, destroy ivi-surface, and commit_changes - call set_destination_rectangle, destroy ivi-surface, and commit_changes Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:33:26 +03:00
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
wnd = client_create_ivi_window(client, iviapp, IVI_TEST_SURFACE_ID(0));
tests: test set for ivi-surface bad condition with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - ivi_layout_runner with basic_test_names[] - surface with bad opacity - destroy ivi/wl_surface and call get_surface - commit_changes_after_properties_set_surface_destroy with surface_property_commit_changes_test_names[] - call set_visibility, destroy ivi-surface, and commit_changes - call set_opacity, destroy ivi-surface, and commit_changes - call set_orientation, destroy ivi-surface, and commit_changes - call set_dimension, destroy ivi-surface, and commit_changes - call set_position, destroy ivi-surface, and commit_changes - call set_source_rectangle, destroy ivi-surface, and commit_changes - call set_destination_rectangle, destroy ivi-surface, and commit_changes Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:33:26 +03:00
runner_run(runner, *test_name);
ivi_window_destroy(wnd);
runner_run(runner, "ivi_layout_commit_changes");
runner_destroy(runner);
tests: fix leaks in ivi-layout-test-client Everything here was systematically leaking client and iviapp. Discovered by ASan on ./tests/test-ivi-layout-client Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2021-06-14 14:38:04 +03:00
ivi_application_destroy(iviapp);
client_destroy(client);
tests: test set for ivi-surface bad condition with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - ivi_layout_runner with basic_test_names[] - surface with bad opacity - destroy ivi/wl_surface and call get_surface - commit_changes_after_properties_set_surface_destroy with surface_property_commit_changes_test_names[] - call set_visibility, destroy ivi-surface, and commit_changes - call set_opacity, destroy ivi-surface, and commit_changes - call set_orientation, destroy ivi-surface, and commit_changes - call set_dimension, destroy ivi-surface, and commit_changes - call set_position, destroy ivi-surface, and commit_changes - call set_source_rectangle, destroy ivi-surface, and commit_changes - call set_destination_rectangle, destroy ivi-surface, and commit_changes Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:33:26 +03:00
}
TEST(get_surface_after_destroy_ivi_surface)
{
struct client *client;
struct runner *runner;
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
struct ivi_application *iviapp;
tests: test set for ivi-surface bad condition with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - ivi_layout_runner with basic_test_names[] - surface with bad opacity - destroy ivi/wl_surface and call get_surface - commit_changes_after_properties_set_surface_destroy with surface_property_commit_changes_test_names[] - call set_visibility, destroy ivi-surface, and commit_changes - call set_opacity, destroy ivi-surface, and commit_changes - call set_orientation, destroy ivi-surface, and commit_changes - call set_dimension, destroy ivi-surface, and commit_changes - call set_position, destroy ivi-surface, and commit_changes - call set_source_rectangle, destroy ivi-surface, and commit_changes - call set_destination_rectangle, destroy ivi-surface, and commit_changes Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:33:26 +03:00
struct ivi_window *wnd;
client = create_client();
runner = client_create_runner(client);
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
iviapp = get_ivi_application(client);
tests: test set for ivi-surface bad condition with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - ivi_layout_runner with basic_test_names[] - surface with bad opacity - destroy ivi/wl_surface and call get_surface - commit_changes_after_properties_set_surface_destroy with surface_property_commit_changes_test_names[] - call set_visibility, destroy ivi-surface, and commit_changes - call set_opacity, destroy ivi-surface, and commit_changes - call set_orientation, destroy ivi-surface, and commit_changes - call set_dimension, destroy ivi-surface, and commit_changes - call set_position, destroy ivi-surface, and commit_changes - call set_source_rectangle, destroy ivi-surface, and commit_changes - call set_destination_rectangle, destroy ivi-surface, and commit_changes Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:33:26 +03:00
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
wnd = client_create_ivi_window(client, iviapp, IVI_TEST_SURFACE_ID(0));
tests: test set for ivi-surface bad condition with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - ivi_layout_runner with basic_test_names[] - surface with bad opacity - destroy ivi/wl_surface and call get_surface - commit_changes_after_properties_set_surface_destroy with surface_property_commit_changes_test_names[] - call set_visibility, destroy ivi-surface, and commit_changes - call set_opacity, destroy ivi-surface, and commit_changes - call set_orientation, destroy ivi-surface, and commit_changes - call set_dimension, destroy ivi-surface, and commit_changes - call set_position, destroy ivi-surface, and commit_changes - call set_source_rectangle, destroy ivi-surface, and commit_changes - call set_destination_rectangle, destroy ivi-surface, and commit_changes Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:33:26 +03:00
ivi_surface_destroy(wnd->ivi_surface);
runner_run(runner, "get_surface_after_destroy_surface");
wl_surface_destroy(wnd->wl_surface);
free(wnd);
runner_destroy(runner);
tests: fix leaks in ivi-layout-test-client Everything here was systematically leaking client and iviapp. Discovered by ASan on ./tests/test-ivi-layout-client Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2021-06-14 14:38:04 +03:00
ivi_application_destroy(iviapp);
client_destroy(client);
tests: test set for ivi-surface bad condition with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - ivi_layout_runner with basic_test_names[] - surface with bad opacity - destroy ivi/wl_surface and call get_surface - commit_changes_after_properties_set_surface_destroy with surface_property_commit_changes_test_names[] - call set_visibility, destroy ivi-surface, and commit_changes - call set_opacity, destroy ivi-surface, and commit_changes - call set_orientation, destroy ivi-surface, and commit_changes - call set_dimension, destroy ivi-surface, and commit_changes - call set_position, destroy ivi-surface, and commit_changes - call set_source_rectangle, destroy ivi-surface, and commit_changes - call set_destination_rectangle, destroy ivi-surface, and commit_changes Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:33:26 +03:00
}
TEST(get_surface_after_destroy_wl_surface)
{
struct client *client;
struct runner *runner;
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
struct ivi_application *iviapp;
tests: test set for ivi-surface bad condition with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - ivi_layout_runner with basic_test_names[] - surface with bad opacity - destroy ivi/wl_surface and call get_surface - commit_changes_after_properties_set_surface_destroy with surface_property_commit_changes_test_names[] - call set_visibility, destroy ivi-surface, and commit_changes - call set_opacity, destroy ivi-surface, and commit_changes - call set_orientation, destroy ivi-surface, and commit_changes - call set_dimension, destroy ivi-surface, and commit_changes - call set_position, destroy ivi-surface, and commit_changes - call set_source_rectangle, destroy ivi-surface, and commit_changes - call set_destination_rectangle, destroy ivi-surface, and commit_changes Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:33:26 +03:00
struct ivi_window *wnd;
client = create_client();
runner = client_create_runner(client);
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
iviapp = get_ivi_application(client);
tests: test set for ivi-surface bad condition with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - ivi_layout_runner with basic_test_names[] - surface with bad opacity - destroy ivi/wl_surface and call get_surface - commit_changes_after_properties_set_surface_destroy with surface_property_commit_changes_test_names[] - call set_visibility, destroy ivi-surface, and commit_changes - call set_opacity, destroy ivi-surface, and commit_changes - call set_orientation, destroy ivi-surface, and commit_changes - call set_dimension, destroy ivi-surface, and commit_changes - call set_position, destroy ivi-surface, and commit_changes - call set_source_rectangle, destroy ivi-surface, and commit_changes - call set_destination_rectangle, destroy ivi-surface, and commit_changes Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:33:26 +03:00
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
wnd = client_create_ivi_window(client, iviapp, IVI_TEST_SURFACE_ID(0));
tests: test set for ivi-surface bad condition with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - ivi_layout_runner with basic_test_names[] - surface with bad opacity - destroy ivi/wl_surface and call get_surface - commit_changes_after_properties_set_surface_destroy with surface_property_commit_changes_test_names[] - call set_visibility, destroy ivi-surface, and commit_changes - call set_opacity, destroy ivi-surface, and commit_changes - call set_orientation, destroy ivi-surface, and commit_changes - call set_dimension, destroy ivi-surface, and commit_changes - call set_position, destroy ivi-surface, and commit_changes - call set_source_rectangle, destroy ivi-surface, and commit_changes - call set_destination_rectangle, destroy ivi-surface, and commit_changes Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:33:26 +03:00
wl_surface_destroy(wnd->wl_surface);
runner_run(runner, "get_surface_after_destroy_surface");
ivi_surface_destroy(wnd->ivi_surface);
free(wnd);
runner_destroy(runner);
tests: fix leaks in ivi-layout-test-client Everything here was systematically leaking client and iviapp. Discovered by ASan on ./tests/test-ivi-layout-client Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2021-06-14 14:38:04 +03:00
ivi_application_destroy(iviapp);
client_destroy(client);
tests: test set for ivi-surface bad condition with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - ivi_layout_runner with basic_test_names[] - surface with bad opacity - destroy ivi/wl_surface and call get_surface - commit_changes_after_properties_set_surface_destroy with surface_property_commit_changes_test_names[] - call set_visibility, destroy ivi-surface, and commit_changes - call set_opacity, destroy ivi-surface, and commit_changes - call set_orientation, destroy ivi-surface, and commit_changes - call set_dimension, destroy ivi-surface, and commit_changes - call set_position, destroy ivi-surface, and commit_changes - call set_source_rectangle, destroy ivi-surface, and commit_changes - call set_destination_rectangle, destroy ivi-surface, and commit_changes Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:33:26 +03:00
}
tests: test set for ivi-layer normal use case with helper client These test are implemented on test suite framework, which provides helper client. Following features are tested, - render order of ivi-surfaces on ivi-layer Signed-off-by: Nobuhiko Tanibata <nobuhiko_tanibata@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:34:09 +03:00
TEST_P(ivi_layout_layer_render_order_runner, render_order_test_names)
{
/* an element from render_order_test_names */
const char * const *test_name = data;
struct client *client;
struct runner *runner;
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
struct ivi_application *iviapp;
tests: test set for ivi-layer normal use case with helper client These test are implemented on test suite framework, which provides helper client. Following features are tested, - render order of ivi-surfaces on ivi-layer Signed-off-by: Nobuhiko Tanibata <nobuhiko_tanibata@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:34:09 +03:00
struct ivi_window *winds[3];
client = create_client();
runner = client_create_runner(client);
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
iviapp = get_ivi_application(client);
tests: test set for ivi-layer normal use case with helper client These test are implemented on test suite framework, which provides helper client. Following features are tested, - render order of ivi-surfaces on ivi-layer Signed-off-by: Nobuhiko Tanibata <nobuhiko_tanibata@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:34:09 +03:00
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
winds[0] = client_create_ivi_window(client, iviapp,
IVI_TEST_SURFACE_ID(0));
winds[1] = client_create_ivi_window(client, iviapp,
IVI_TEST_SURFACE_ID(1));
winds[2] = client_create_ivi_window(client, iviapp,
IVI_TEST_SURFACE_ID(2));
tests: test set for ivi-layer normal use case with helper client These test are implemented on test suite framework, which provides helper client. Following features are tested, - render order of ivi-surfaces on ivi-layer Signed-off-by: Nobuhiko Tanibata <nobuhiko_tanibata@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:34:09 +03:00
runner_run(runner, *test_name);
ivi_window_destroy(winds[0]);
ivi_window_destroy(winds[1]);
ivi_window_destroy(winds[2]);
runner_destroy(runner);
tests: fix leaks in ivi-layout-test-client Everything here was systematically leaking client and iviapp. Discovered by ASan on ./tests/test-ivi-layout-client Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2021-06-14 14:38:04 +03:00
ivi_application_destroy(iviapp);
client_destroy(client);
tests: test set for ivi-layer normal use case with helper client These test are implemented on test suite framework, which provides helper client. Following features are tested, - render order of ivi-surfaces on ivi-layer Signed-off-by: Nobuhiko Tanibata <nobuhiko_tanibata@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:34:09 +03:00
}
tests: test set for ivi-layer bad condition with helper-client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - bad render order of ivi-surface on ivi-layer - call commitchanges after a ivi_surface in render order is destoryed Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:34:42 +03:00
TEST(destroy_surface_after_layer_render_order)
{
struct client *client;
struct runner *runner;
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
struct ivi_application *iviapp;
tests: test set for ivi-layer bad condition with helper-client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - bad render order of ivi-surface on ivi-layer - call commitchanges after a ivi_surface in render order is destoryed Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:34:42 +03:00
struct ivi_window *winds[3];
client = create_client();
runner = client_create_runner(client);
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
iviapp = get_ivi_application(client);
tests: test set for ivi-layer bad condition with helper-client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - bad render order of ivi-surface on ivi-layer - call commitchanges after a ivi_surface in render order is destoryed Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:34:42 +03:00
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
winds[0] = client_create_ivi_window(client, iviapp,
IVI_TEST_SURFACE_ID(0));
winds[1] = client_create_ivi_window(client, iviapp,
IVI_TEST_SURFACE_ID(1));
winds[2] = client_create_ivi_window(client, iviapp,
IVI_TEST_SURFACE_ID(2));
tests: test set for ivi-layer bad condition with helper-client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - bad render order of ivi-surface on ivi-layer - call commitchanges after a ivi_surface in render order is destoryed Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:34:42 +03:00
runner_run(runner, "test_layer_render_order_destroy_one_surface_p1");
ivi_window_destroy(winds[1]);
runner_run(runner, "test_layer_render_order_destroy_one_surface_p2");
ivi_window_destroy(winds[0]);
ivi_window_destroy(winds[2]);
runner_destroy(runner);
tests: fix leaks in ivi-layout-test-client Everything here was systematically leaking client and iviapp. Discovered by ASan on ./tests/test-ivi-layout-client Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2021-06-14 14:38:04 +03:00
ivi_application_destroy(iviapp);
client_destroy(client);
tests: test set for ivi-layer bad condition with helper-client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - bad render order of ivi-surface on ivi-layer - call commitchanges after a ivi_surface in render order is destoryed Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:34:42 +03:00
}
TEST(commit_changes_after_render_order_set_surface_destroy)
{
struct client *client;
struct runner *runner;
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
struct ivi_application *iviapp;
tests: test set for ivi-layer bad condition with helper-client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - bad render order of ivi-surface on ivi-layer - call commitchanges after a ivi_surface in render order is destoryed Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:34:42 +03:00
struct ivi_window *winds[3];
client = create_client();
runner = client_create_runner(client);
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
iviapp = get_ivi_application(client);
tests: test set for ivi-layer bad condition with helper-client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - bad render order of ivi-surface on ivi-layer - call commitchanges after a ivi_surface in render order is destoryed Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:34:42 +03:00
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
winds[0] = client_create_ivi_window(client, iviapp,
IVI_TEST_SURFACE_ID(0));
winds[1] = client_create_ivi_window(client, iviapp,
IVI_TEST_SURFACE_ID(1));
winds[2] = client_create_ivi_window(client, iviapp,
IVI_TEST_SURFACE_ID(2));
tests: test set for ivi-layer bad condition with helper-client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - bad render order of ivi-surface on ivi-layer - call commitchanges after a ivi_surface in render order is destoryed Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:34:42 +03:00
runner_run(runner, "commit_changes_after_render_order_set_surface_destroy");
ivi_window_destroy(winds[1]);
runner_run(runner, "ivi_layout_commit_changes");
runner_run(runner, "cleanup_layer");
ivi_window_destroy(winds[0]);
ivi_window_destroy(winds[2]);
runner_destroy(runner);
tests: fix leaks in ivi-layout-test-client Everything here was systematically leaking client and iviapp. Discovered by ASan on ./tests/test-ivi-layout-client Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2021-06-14 14:38:04 +03:00
ivi_application_destroy(iviapp);
client_destroy(client);
tests: test set for ivi-layer bad condition with helper-client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - bad render order of ivi-surface on ivi-layer - call commitchanges after a ivi_surface in render order is destoryed Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:34:42 +03:00
}
tests: test set for ivi-shell notification normal use case with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - notification of adding ivi-surface - notification of ivi-surface configure - notification of creating ivi-surface - notification of removing ivi-surface Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:35:58 +03:00
TEST(ivi_layout_surface_configure_notification)
{
struct client *client;
struct runner *runner;
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
struct ivi_application *iviapp;
tests: test set for ivi-shell notification normal use case with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - notification of adding ivi-surface - notification of ivi-surface configure - notification of creating ivi-surface - notification of removing ivi-surface Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:35:58 +03:00
struct ivi_window *wind;
tests: ivi_layout-test to use create_shm_buffer_a8r8g8b8() This removes the uses of create_shm_buffer() from this test. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Daniel Stone <daniels@collabora.com>
2016-05-20 18:01:05 +03:00
struct buffer *buffer;
tests: test set for ivi-shell notification normal use case with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - notification of adding ivi-surface - notification of ivi-surface configure - notification of creating ivi-surface - notification of removing ivi-surface Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:35:58 +03:00
client = create_client();
runner = client_create_runner(client);
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
iviapp = get_ivi_application(client);
tests: test set for ivi-shell notification normal use case with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - notification of adding ivi-surface - notification of ivi-surface configure - notification of creating ivi-surface - notification of removing ivi-surface Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:35:58 +03:00
runner_run(runner, "surface_configure_notification_p1");
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
wind = client_create_ivi_window(client, iviapp, IVI_TEST_SURFACE_ID(0));
tests: test set for ivi-shell notification normal use case with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - notification of adding ivi-surface - notification of ivi-surface configure - notification of creating ivi-surface - notification of removing ivi-surface Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:35:58 +03:00
tests: ivi_layout-test to use create_shm_buffer_a8r8g8b8() This removes the uses of create_shm_buffer() from this test. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Daniel Stone <daniels@collabora.com>
2016-05-20 18:01:05 +03:00
buffer = create_shm_buffer_a8r8g8b8(client, 200, 300);
tests: test set for ivi-shell notification normal use case with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - notification of adding ivi-surface - notification of ivi-surface configure - notification of creating ivi-surface - notification of removing ivi-surface Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:35:58 +03:00
tests: ivi_layout-test to use create_shm_buffer_a8r8g8b8() This removes the uses of create_shm_buffer() from this test. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Daniel Stone <daniels@collabora.com>
2016-05-20 18:01:05 +03:00
wl_surface_attach(wind->wl_surface, buffer->proxy, 0, 0);
tests: test set for ivi-shell notification normal use case with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - notification of adding ivi-surface - notification of ivi-surface configure - notification of creating ivi-surface - notification of removing ivi-surface Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:35:58 +03:00
wl_surface_damage(wind->wl_surface, 0, 0, 20, 30);
wl_surface_commit(wind->wl_surface);
runner_run(runner, "surface_configure_notification_p2");
tests: ivi_layout-test to use create_shm_buffer_a8r8g8b8() This removes the uses of create_shm_buffer() from this test. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Daniel Stone <daniels@collabora.com>
2016-05-20 18:01:05 +03:00
wl_surface_attach(wind->wl_surface, buffer->proxy, 0, 0);
tests: test set for ivi-shell notification normal use case with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - notification of adding ivi-surface - notification of ivi-surface configure - notification of creating ivi-surface - notification of removing ivi-surface Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:35:58 +03:00
wl_surface_damage(wind->wl_surface, 0, 0, 40, 50);
wl_surface_commit(wind->wl_surface);
runner_run(runner, "surface_configure_notification_p3");
tests: ivi_layout-test to use create_shm_buffer_a8r8g8b8() This removes the uses of create_shm_buffer() from this test. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Daniel Stone <daniels@collabora.com>
2016-05-20 18:01:05 +03:00
buffer_destroy(buffer);
tests: test set for ivi-shell notification normal use case with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - notification of adding ivi-surface - notification of ivi-surface configure - notification of creating ivi-surface - notification of removing ivi-surface Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:35:58 +03:00
ivi_window_destroy(wind);
runner_destroy(runner);
tests: fix leaks in ivi-layout-test-client Everything here was systematically leaking client and iviapp. Discovered by ASan on ./tests/test-ivi-layout-client Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2021-06-14 14:38:04 +03:00
ivi_application_destroy(iviapp);
client_destroy(client);
tests: test set for ivi-shell notification normal use case with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - notification of adding ivi-surface - notification of ivi-surface configure - notification of creating ivi-surface - notification of removing ivi-surface Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:35:58 +03:00
}
TEST(ivi_layout_surface_create_notification)
{
struct client *client;
struct runner *runner;
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
struct ivi_application *iviapp;
tests: test set for ivi-shell notification normal use case with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - notification of adding ivi-surface - notification of ivi-surface configure - notification of creating ivi-surface - notification of removing ivi-surface Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:35:58 +03:00
struct ivi_window *wind;
client = create_client();
runner = client_create_runner(client);
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
iviapp = get_ivi_application(client);
tests: test set for ivi-shell notification normal use case with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - notification of adding ivi-surface - notification of ivi-surface configure - notification of creating ivi-surface - notification of removing ivi-surface Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:35:58 +03:00
runner_run(runner, "surface_create_notification_p1");
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
wind = client_create_ivi_window(client, iviapp, IVI_TEST_SURFACE_ID(0));
tests: test set for ivi-shell notification normal use case with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - notification of adding ivi-surface - notification of ivi-surface configure - notification of creating ivi-surface - notification of removing ivi-surface Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:35:58 +03:00
runner_run(runner, "surface_create_notification_p2");
ivi_window_destroy(wind);
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
wind = client_create_ivi_window(client, iviapp, IVI_TEST_SURFACE_ID(0));
tests: test set for ivi-shell notification normal use case with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - notification of adding ivi-surface - notification of ivi-surface configure - notification of creating ivi-surface - notification of removing ivi-surface Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:35:58 +03:00
runner_run(runner, "surface_create_notification_p3");
ivi_window_destroy(wind);
runner_destroy(runner);
tests: fix leaks in ivi-layout-test-client Everything here was systematically leaking client and iviapp. Discovered by ASan on ./tests/test-ivi-layout-client Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2021-06-14 14:38:04 +03:00
ivi_application_destroy(iviapp);
client_destroy(client);
tests: test set for ivi-shell notification normal use case with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - notification of adding ivi-surface - notification of ivi-surface configure - notification of creating ivi-surface - notification of removing ivi-surface Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:35:58 +03:00
}
TEST(ivi_layout_surface_remove_notification)
{
struct client *client;
struct runner *runner;
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
struct ivi_application *iviapp;
tests: test set for ivi-shell notification normal use case with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - notification of adding ivi-surface - notification of ivi-surface configure - notification of creating ivi-surface - notification of removing ivi-surface Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:35:58 +03:00
struct ivi_window *wind;
client = create_client();
runner = client_create_runner(client);
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
iviapp = get_ivi_application(client);
tests: test set for ivi-shell notification normal use case with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - notification of adding ivi-surface - notification of ivi-surface configure - notification of creating ivi-surface - notification of removing ivi-surface Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:35:58 +03:00
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
wind = client_create_ivi_window(client, iviapp, IVI_TEST_SURFACE_ID(0));
tests: test set for ivi-shell notification normal use case with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - notification of adding ivi-surface - notification of ivi-surface configure - notification of creating ivi-surface - notification of removing ivi-surface Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:35:58 +03:00
runner_run(runner, "surface_remove_notification_p1");
ivi_window_destroy(wind);
runner_run(runner, "surface_remove_notification_p2");
tests: remove static data from ivi-layout-test-client Using static data will mess things up when the test harness no longer fork()'s each sub-test. Hence it needs to be converted to "normal" data. Unfortunately here the cached value was actually used, so keeping that behaviour is a handful. Yes, it was all leaked also before. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-11-05 18:03:34 +03:00
wind = client_create_ivi_window(client, iviapp, IVI_TEST_SURFACE_ID(0));
tests: test set for ivi-shell notification normal use case with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - notification of adding ivi-surface - notification of ivi-surface configure - notification of creating ivi-surface - notification of removing ivi-surface Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:35:58 +03:00
ivi_window_destroy(wind);
runner_run(runner, "surface_remove_notification_p3");
runner_destroy(runner);
tests: fix leaks in ivi-layout-test-client Everything here was systematically leaking client and iviapp. Discovered by ASan on ./tests/test-ivi-layout-client Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2021-06-14 14:38:04 +03:00
ivi_application_destroy(iviapp);
client_destroy(client);
tests: test set for ivi-shell notification normal use case with helper client These tests are implemented on test suite framework, which provides helper client. Following features are tested, - notification of adding ivi-surface - notification of ivi-surface configure - notification of creating ivi-surface - notification of removing ivi-surface Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
2015-06-22 09:35:58 +03:00
}
Reference in New Issue Copy Permalink