2012-12-12 16:26:38 +04:00
|
|
|
#!/bin/bash
|
2012-04-12 20:54:14 +04:00
|
|
|
|
2015-04-03 05:16:52 +03:00
|
|
|
TEST_FILE=${1##*/}
|
|
|
|
TEST_NAME=${TEST_FILE%.*}
|
2013-09-11 09:58:08 +04:00
|
|
|
|
2015-04-03 05:16:56 +03:00
|
|
|
if [ -z "$TEST_NAME" ]; then
|
2013-09-11 09:58:08 +04:00
|
|
|
echo "usage: $(basename $0) <test name>"
|
|
|
|
exit 1;
|
|
|
|
fi
|
|
|
|
|
2014-02-01 02:03:09 +04:00
|
|
|
WESTON=$abs_builddir/weston
|
2012-12-12 16:26:38 +04:00
|
|
|
LOGDIR=$abs_builddir/logs
|
|
|
|
|
2015-04-16 01:10:31 +03:00
|
|
|
mkdir -p "$LOGDIR" || exit
|
2012-12-12 16:26:38 +04:00
|
|
|
|
2015-04-03 05:16:53 +03:00
|
|
|
SERVERLOG="$LOGDIR/${TEST_NAME}-serverlog.txt"
|
|
|
|
OUTLOG="$LOGDIR/${TEST_NAME}-log.txt"
|
2012-12-12 16:26:38 +04:00
|
|
|
|
2015-04-16 01:10:31 +03:00
|
|
|
rm -f "$SERVERLOG" || exit
|
2012-04-12 20:54:14 +04:00
|
|
|
|
2015-04-03 05:16:56 +03:00
|
|
|
BACKEND=${BACKEND:-headless-backend.so}
|
2012-12-15 01:19:43 +04:00
|
|
|
|
2015-03-24 16:56:16 +03:00
|
|
|
MODDIR=$abs_builddir/.libs
|
|
|
|
|
|
|
|
SHELL_PLUGIN=$MODDIR/desktop-shell.so
|
|
|
|
TEST_PLUGIN=$MODDIR/weston-test.so
|
2014-02-07 12:34:47 +04:00
|
|
|
|
2015-04-16 01:31:11 +03:00
|
|
|
CONFIG_FILE="${TEST_NAME}.ini"
|
|
|
|
|
|
|
|
if [ -e "${abs_builddir}/${CONFIG_FILE}" ]; then
|
|
|
|
CONFIG="--config=${abs_builddir}/${CONFIG_FILE}"
|
|
|
|
elif [ -e "${abs_top_srcdir}/tests/${CONFIG_FILE}" ]; then
|
|
|
|
CONFIG="--config=${abs_top_srcdir}/tests/${CONFIG_FILE}"
|
|
|
|
else
|
|
|
|
CONFIG="--no-config"
|
|
|
|
fi
|
|
|
|
|
2015-04-03 05:16:52 +03:00
|
|
|
case $TEST_FILE in
|
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
|
|
|
ivi-*.la|ivi-*.so)
|
|
|
|
SHELL_PLUGIN=$MODDIR/ivi-shell.so
|
|
|
|
|
2016-05-13 16:29:30 +03:00
|
|
|
set -x
|
2018-02-07 00:18:37 +03:00
|
|
|
WESTON_DATA_DIR=$abs_top_srcdir/data \
|
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
|
|
|
WESTON_BUILD_DIR=$abs_builddir \
|
2015-05-22 22:49:52 +03:00
|
|
|
WESTON_TEST_REFERENCE_PATH=$abs_top_srcdir/tests/reference \
|
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
|
|
|
$WESTON --backend=$MODDIR/$BACKEND \
|
2018-02-14 13:06:54 +03:00
|
|
|
--no-config \
|
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
|
|
|
--shell=$SHELL_PLUGIN \
|
|
|
|
--socket=test-${TEST_NAME} \
|
2018-01-25 16:36:13 +03:00
|
|
|
--modules=$TEST_PLUGIN,$MODDIR/${TEST_FILE/.la/.so}\
|
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
|
|
|
--log="$SERVERLOG" \
|
|
|
|
&> "$OUTLOG"
|
|
|
|
;;
|
2012-12-08 01:50:31 +04:00
|
|
|
*.la|*.so)
|
2016-05-13 16:29:30 +03:00
|
|
|
set -x
|
2018-02-07 00:18:37 +03:00
|
|
|
WESTON_DATA_DIR=$abs_top_srcdir/data \
|
2014-08-21 20:32:38 +04:00
|
|
|
WESTON_BUILD_DIR=$abs_builddir \
|
2015-05-22 22:49:52 +03:00
|
|
|
WESTON_TEST_REFERENCE_PATH=$abs_top_srcdir/tests/reference \
|
2015-03-24 16:56:16 +03:00
|
|
|
$WESTON --backend=$MODDIR/$BACKEND \
|
2015-12-22 00:38:51 +03:00
|
|
|
${CONFIG} \
|
2014-05-07 17:26:28 +04:00
|
|
|
--shell=$SHELL_PLUGIN \
|
2015-04-03 05:16:52 +03:00
|
|
|
--socket=test-${TEST_NAME} \
|
2016-07-04 15:34:48 +03:00
|
|
|
--xwayland \
|
|
|
|
--modules=$MODDIR/${TEST_FILE/.la/.so} \
|
2012-12-12 16:26:38 +04:00
|
|
|
--log="$SERVERLOG" \
|
|
|
|
&> "$OUTLOG"
|
2012-12-08 01:50:31 +04:00
|
|
|
;;
|
2015-03-23 14:55:06 +03:00
|
|
|
ivi-*.weston)
|
|
|
|
SHELL_PLUGIN=$MODDIR/ivi-shell.so
|
|
|
|
|
2016-05-13 16:29:30 +03:00
|
|
|
set -x
|
2018-02-07 00:18:37 +03:00
|
|
|
WESTON_DATA_DIR=$abs_top_srcdir/data \
|
2015-03-23 14:55:06 +03:00
|
|
|
WESTON_BUILD_DIR=$abs_builddir \
|
2015-05-22 22:49:52 +03:00
|
|
|
WESTON_TEST_REFERENCE_PATH=$abs_top_srcdir/tests/reference \
|
2015-12-22 00:38:51 +03:00
|
|
|
WESTON_TEST_CLIENT_PATH=$abs_builddir/$TEST_FILE \
|
|
|
|
$WESTON --backend=$MODDIR/$BACKEND \
|
2018-02-14 13:06:54 +03:00
|
|
|
--no-config \
|
2015-03-23 14:55:06 +03:00
|
|
|
--shell=$SHELL_PLUGIN \
|
2015-12-22 00:38:51 +03:00
|
|
|
--socket=test-${TEST_NAME} \
|
2015-03-23 14:55:06 +03:00
|
|
|
--modules=$TEST_PLUGIN \
|
2015-12-22 00:38:51 +03:00
|
|
|
--log="$SERVERLOG" \
|
2015-03-23 14:55:06 +03:00
|
|
|
$($abs_builddir/$TESTNAME --params) \
|
|
|
|
&> "$OUTLOG"
|
|
|
|
;;
|
2012-12-08 01:50:31 +04:00
|
|
|
*)
|
2016-05-13 16:29:30 +03:00
|
|
|
set -x
|
2018-02-07 00:18:37 +03:00
|
|
|
WESTON_DATA_DIR=$abs_top_srcdir/data \
|
2014-08-21 20:32:38 +04:00
|
|
|
WESTON_BUILD_DIR=$abs_builddir \
|
2015-05-22 22:49:52 +03:00
|
|
|
WESTON_TEST_REFERENCE_PATH=$abs_top_srcdir/tests/reference \
|
2015-12-22 00:38:51 +03:00
|
|
|
WESTON_TEST_CLIENT_PATH=$abs_builddir/$TEST_FILE \
|
|
|
|
$WESTON --backend=$MODDIR/$BACKEND \
|
|
|
|
${CONFIG} \
|
2014-05-07 17:26:28 +04:00
|
|
|
--shell=$SHELL_PLUGIN \
|
2015-12-22 00:38:51 +03:00
|
|
|
--socket=test-${TEST_NAME} \
|
2016-07-04 15:34:48 +03:00
|
|
|
--xwayland \
|
|
|
|
--modules=$TEST_PLUGIN \
|
2015-12-22 00:38:51 +03:00
|
|
|
--log="$SERVERLOG" \
|
2015-04-03 05:16:52 +03:00
|
|
|
$($abs_builddir/$TEST_FILE --params) \
|
2012-12-12 16:26:38 +04:00
|
|
|
&> "$OUTLOG"
|
2012-12-08 01:50:31 +04:00
|
|
|
esac
|