239 lines
27 KiB
HTML
239 lines
27 KiB
HTML
<!-- HTML header for doxygen 1.9.1-->
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
|
|
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
|
|
<meta name="generator" content="Doxygen 1.15.0"/>
|
|
<meta name="viewport" content="width=device-width, initial-scale=1"/>
|
|
<title>L4Re Operating System Framework: test.mk - Test Application Role</title>
|
|
<link href="tabs.css" rel="stylesheet" type="text/css"/>
|
|
<script type="text/javascript" src="jquery.js"></script>
|
|
<script type="text/javascript" src="dynsections.js"></script>
|
|
<link href="navtree.css" rel="stylesheet" type="text/css"/>
|
|
<script type="text/javascript" src="navtreedata.js"></script>
|
|
<script type="text/javascript" src="navtree.js"></script>
|
|
<script type="text/javascript" src="cookie.js"></script>
|
|
<link href="search/search.css" rel="stylesheet" type="text/css"/>
|
|
<script type="text/javascript" src="search/searchdata.js"></script>
|
|
<script type="text/javascript" src="search/search.js"></script>
|
|
<link href="doxygen.css" rel="stylesheet" type="text/css" />
|
|
<link href="doxygen-awesome.css" rel="stylesheet" type="text/css"/>
|
|
<link href="l4re-awesome.css" rel="stylesheet" type="text/css"/>
|
|
</head>
|
|
<body>
|
|
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
|
|
<div id="titlearea">
|
|
<table cellspacing="0" cellpadding="0">
|
|
<tbody>
|
|
<tr style="height: 56px;">
|
|
<td id="projectlogo"><img alt="Logo" src="L4Re_rgb_logo_quer_hg_h55.png"/></td>
|
|
<td id="projectalign" style="padding-left: 0.5em;">
|
|
<div id="projectname">L4Re Operating System Framework
|
|
</div>
|
|
<div id="projectbrief">Interface and Usage Documentation</div>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
<!-- end header part -->
|
|
<!-- Generated by Doxygen 1.15.0 -->
|
|
<script type="text/javascript">
|
|
var searchBox = new SearchBox("searchBox", "search/",'.html');
|
|
</script>
|
|
<script type="text/javascript">
|
|
$(function() { codefold.init(); });
|
|
</script>
|
|
<script type="text/javascript" src="menudata.js"></script>
|
|
<script type="text/javascript" src="menu.js"></script>
|
|
<script type="text/javascript">
|
|
$(function() {
|
|
initMenu('',true,false,'search.php','Search',true);
|
|
$(function() { init_search(); });
|
|
});
|
|
</script>
|
|
<div id="main-nav"></div>
|
|
</div><!-- top -->
|
|
<div id="side-nav" class="ui-resizable side-nav-resizable">
|
|
<div id="nav-tree">
|
|
<div id="nav-tree-contents">
|
|
<div id="nav-sync" class="sync"></div>
|
|
</div>
|
|
</div>
|
|
<div id="splitbar" style="-moz-user-select:none;"
|
|
class="ui-resizable-handle">
|
|
</div>
|
|
</div>
|
|
<script type="text/javascript">
|
|
$(function(){initNavTree('bid_role_test.html','',''); });
|
|
</script>
|
|
<div id="container">
|
|
<div id="doc-content">
|
|
<!-- window showing the filter options -->
|
|
<div id="MSearchSelectWindow"
|
|
onmouseover="return searchBox.OnSearchSelectShow()"
|
|
onmouseout="return searchBox.OnSearchSelectHide()"
|
|
onkeydown="return searchBox.OnSearchSelectKey(event)">
|
|
</div>
|
|
|
|
<!-- iframe showing the search results (closed by default) -->
|
|
<div id="MSearchResultsWindow">
|
|
<div id="MSearchResults">
|
|
<div class="SRPage">
|
|
<div id="SRIndex">
|
|
<div id="SRResults"></div>
|
|
<div class="SRStatus" id="Loading">Loading...</div>
|
|
<div class="SRStatus" id="Searching">Searching...</div>
|
|
<div class="SRStatus" id="NoMatches">No Matches</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div><div class="header">
|
|
<div class="headertitle"><div class="title">test.mk - Test Application Role </div></div>
|
|
</div><!--header-->
|
|
<div class="contents">
|
|
<div class="textblock"><p>The test role is very similar to the application role, it also builds an executable binary. The difference is that is also builds for each target a test script that executes the test target either on the host (MODE=host) or a target platform (currently only qemu).</p>
|
|
<p>The role accepts all make variables that are accepted by the application role. The only difference is that the <span class="tt">TARGET</span> variable is not required. If it is missing, the source directory will be scanned for source files that fit the pattern <span class="tt">test_*.c[c]</span> and create one target for each of them.</p>
|
|
<dl class="section note"><dt>Note</dt><dd>It is possible to still use SRC_C[C] when targets are determined automatically. In that case the specified sources will be used in addition* to the main <span class="tt">test_*.c[c]</span> source.</dd></dl>
|
|
<p>In addition to the variables above, there are a number of variables that control how the test is executed. All these variables may be used as a global variable that applies to all test or, if the target name is added as a suffix, set for a specific target only.</p>
|
|
<dl class="section user"><dt><span class="tt">TEST_TARGET</span></dt><dd>Name of binary containing the test (default: same as <span class="tt">TARGET</span>).</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">TARGET_$(ARCH)</span></dt><dd>When TARGET is undefined, these targets are added to the list of targets for the specified architecture. For all targets <span class="tt">SRC_C[C]</span> files must be defined separately.</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">TEST_KERNEL_ARGS</span></dt><dd>Arguments to append to the kernel command line. These are also appended when specifying custom ones via a .t-file's -f parameter or when using -d.</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">TEST_EXPECTED</span></dt><dd>File containing expected output. By default the variable is empty, which means the test binary is expected to produce TAP test output, that can be directly processed. When the <span class="tt">TEST_TAP_PLUGINS</span> variable is given, <span class="tt">TEST_EXPECTED</span> is ignored.</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">TEST_EXPECTED_REPEAT</span></dt><dd>Number of times the expected output should be repeated, by default 1. When set to 0 then output is expected to repeat forever. This is particularly useful to make sure that stress tests that are meant to run in an endless loop are still alive. Note that such endless tests can only be run by directly executing the test script. They will be skipped when run in a test harness like <span class="tt">prove</span>.</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">TEST_TAP_PLUGINS</span></dt><dd>Specify the plugins that are used to process the output of the test run. The syntax is of the values is:</dd></dl>
|
|
<p>plugin1:arg1=a,arg2=b plugin2:arg=foo</p>
|
|
<p>Multiple plugins separated by a space are loaded in order. Spaces are not allowed inside a plugin specification. One or more arguments are optionally passed to the plugin separated by commas and delimited by a colon.</p>
|
|
<p>If the variable is not specified the plugins for TAPOutput and OutputMatching (depending on the TEST_EXPECTED variable) are automatically loaded.</p>
|
|
<p>For the supported plugins and their options please refer to their in-line documentation in tool/lib/L4/TapWrapper/Plugin/. The plugin name corresponds to the file stem name in that directory.</p>
|
|
<dl class="section user"><dt><span class="tt">TEST_TIMEOUT</span></dt><dd>Non-standard timeout after which the test run is aborted (useful for tests involving sleep).</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">NED_CFG</span></dt><dd>LUA configuration file for startup to give to Ned</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">REQUIRED_MODULES</span></dt><dd>Additional modules needed to run the test. By adding <span class="tt">[opts]</span> to the name of a module you can add module options that are reflected in the generated modules.list.</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">BOOTSTRAP_ARGS</span></dt><dd>Additional parameters to supply to bootstrap.</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">QEMU_ARGS</span></dt><dd>Additional parameters to supply to QEMU.</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">MOE_ARGS</span></dt><dd>Additional parameters to supply to moe.</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">TEST_ARGS</span></dt><dd>Additional arguments for the <span class="tt">TEST_STARTER</span> (tapper-wrapper per default).</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">TEST_ROOT_TASK</span></dt><dd>Alternative root task to be used during a test instead of moe.</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">TEST_ROOT_TASK_ARGS</span></dt><dd>Arguments passed to <span class="tt">TEST_ROOT_TASK</span> if <span class="tt">TEST_ROOT_TASK</span> is different from moe.</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">KERNEL_CONF</span></dt><dd>Features the <a class="el" href="namespaceL4Re.html" title="L4Re C++ Interfaces.">L4Re</a> Microkernel must have been compiled with. A space-separated list of config options as used by Kconfig. <span class="tt">run_test</span> looks for a <span class="tt">globalconfig.out</span> file in the same directory as the kernel and checks that all options are enabled. If not, the test is skipped. Has only an effect if the <span class="tt">globalconfig.out</span> file is present.</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">L4RE_CONF</span></dt><dd>Features the <a class="el" href="namespaceL4Re.html" title="L4Re C++ Interfaces.">L4Re</a> userland must have been compiled with. A space-separated list of config options as used by Kconfig. <span class="tt">run_test</span> will look for these in the <span class="tt">.kconfig</span> file in the <a class="el" href="namespaceL4Re.html" title="L4Re C++ Interfaces.">L4Re</a> build directory.</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">L4LINUX_CONF</span></dt><dd>Features the L4Linux kernel must have been compiled with. Similar to <span class="tt">KERNEL_CONF</span> but checks for a <span class="tt">.config</span> file in the directory of the L4Linux kernel.</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">TEST_SETUP</span></dt><dd>Command to execute before the test is run. The test will only be executed if the command returns 0. If the exit code is 69, the test is marked as skipped with the reason provided in the final line of stdout.</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">TEST_LOGFILE</span></dt><dd>Append output of test execution to the given file unless TEST_WORKDIR is given.</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">TEST_WORKDIR</span></dt><dd>Create logs, temp and other files below the given directory. That directory is taken as base dir for more automatically created subdir levels using the current test path, in order to guarantee conflict-free usage when running many different tests with a common workdir. When TEST_WORKDIR is provided then TEST_LOGFILE is ignored as it is organized below workdir.</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">TEST_TAGS</span></dt><dd><p class="startdd">List of conditions for tags provided during execution of a test. A tag can be set to 1, set to 0 or be unspecified via TEST_RUN_TAGS during execution. Therefore there are 4 possible conditions for a tag that can be specified in TEST_TAGS: tag, !tag, +tag and -tag. The following table shows the conditions they represent.</p>
|
|
<table class="markdownTable">
|
|
<tr class="markdownTableHead">
|
|
<th class="markdownTableHeadNone">TEST_RUN_TAGS \ TEST_TAGS </th><th class="markdownTableHeadNone">tag </th><th class="markdownTableHeadNone">!tag </th><th class="markdownTableHeadNone">+tag </th><th class="markdownTableHeadNone">-tag </th></tr>
|
|
<tr class="markdownTableRowOdd">
|
|
<td class="markdownTableBodyNone">tag or tag=1 </td><td class="markdownTableBodyNone">y </td><td class="markdownTableBodyNone"></td><td class="markdownTableBodyNone">y </td><td class="markdownTableBodyNone"></td></tr>
|
|
<tr class="markdownTableRowEven">
|
|
<td class="markdownTableBodyNone">unspecified </td><td class="markdownTableBodyNone"></td><td class="markdownTableBodyNone">y </td><td class="markdownTableBodyNone">y </td><td class="markdownTableBodyNone"></td></tr>
|
|
<tr class="markdownTableRowOdd">
|
|
<td class="markdownTableBodyNone">tag=0 </td><td class="markdownTableBodyNone"></td><td class="markdownTableBodyNone">y </td><td class="markdownTableBodyNone"></td><td class="markdownTableBodyNone">y </td></tr>
|
|
</table>
|
|
<p class="interdd"><em>Example usage:</em></p>
|
|
<p class="interdd">The tag <span class="tt">long-running</span> is used by tests which take a long time and should be skipped by default. These tests are marked with the tag long-running unprefixed.</p>
|
|
<p class="interdd">The tag <span class="tt">hardware</span> is set to 1 at runtime when the tests will run on real hardware. Tests that must not run on real hardware are marked with <span class="tt">!hardware</span>.</p>
|
|
<p class="interdd">The tag <span class="tt">+impl-def</span> is used by tests that test implementation details. Due to the nature of this flag we require the "+" prefix to be used, so they are run by default but can be excluded from execution by setting TEST_RUN_TAGS to impl-def=0 at runtime.</p>
|
|
<p class="enddd">If you want to specify multiple tag conditions they need to be separated with a comma. </p>
|
|
</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">TEST_PLATFORM_ALLOW</span> and <span class="tt">TEST_PLATFORM_DENY</span></dt><dd><p class="startdd">Deny and allow lists of platforms a test is banned from or limited to. If you list platforms in the TEST_PLATFORM_ALLOW variable the test will only be run on these listed platforms and will be skipped on any other platform. If you list platforms in the TEST_PLATFORM_DENY variable the test will be skipped on the listed platforms and will be run on any other platform. You can only use one of these variables per test, not both. See mk/platforms/ for the various identifiers.</p>
|
|
<p class="interdd"><em>Example usage:</em> </p><pre class="fragment"># Do not run this test on the Raspberry Pi platform
|
|
TEST_PLATFORM_DENY_test_xyz := rpi
|
|
|
|
# Only run this test on this test on the RCar3 platform.
|
|
TEST_PLATFORM_ALLOW_test_abc := rcar3
|
|
</pre><p class="enddd"></p>
|
|
</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">TAPARCHIVE</span></dt><dd>Filename for an archive file to store the resulting TAP output.</dd></dl>
|
|
<p>In addition to compiled tests, it is also possible to create tests where the test binary or script comes from a different source. These tests must be listed in <span class="tt">EXTRA_TARGET</span> and for each target a custom <span class="tt">TEST_TARGET</span> must be provided.</p>
|
|
<h2>Running Tests </h2>
|
|
<p>The make role creates a test script which can be found in <span class="tt"><builddir>/test/t/<arch>/<api></span>. It is possible to organise the tests further in subdirectories below by specifying a TEST_GROUP.</p>
|
|
<p>To be able to execute the test, a minimal test environment needs to be set up by exporting the following environment variables:</p>
|
|
<dl class="section user"><dt><span class="tt">KERNEL_<arch></span>, <span class="tt">KERNEL</span></dt><dd><a class="el" href="namespaceL4Re.html" title="L4Re C++ Interfaces.">L4Re</a> Microkernel binary to use. The test runner is able to check if the kernel has all features necessary for the test and skip tests accordingly. In order for this to work, the <span class="tt">globalconfig.out</span> config file from the build directory needs to be available in the same directory as the kernel.</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">L4LX_KERNEL_<arch></span>, <span class="tt">L4LX_KERNEL</span></dt><dd>L4Linux binary to use. This is only required to run tests in <span class="tt">mode=l4linux</span>. If no L4Linux kernel is set then these tests will simply be skipped. The test runner is also able to check if the kernel has all features compiled in that are required to run the test successfully (see make variable <span class="tt">L4LINUX_CONF</span> above). For this to work, the <span class="tt">.config</span> configuration file from the build directory needs to be available in the same directory as the kernel.</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">LINUX_RAMDISK_<arch></span>, <span class="tt">LINUX_RAMDISK</span></dt><dd>Ramdisk to mount as root in L4Linux. This is only required to run tests in <span class="tt">mode=l4linux</span>. If not supplied, L4Linux tests will be skipped. The ramdisk must be set up to start the test directly after the initial startup is finished. The name of the test binary is supplied via the kernel command line option <span class="tt">l4re_testprog</span>. The <span class="tt">tool/test</span> directory contains an example script <span class="tt">launch-l4linux-test</span>. which can be copied onto the ramdisk and started by the init script.</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">TEST_HWCONFIG</span> and <span class="tt">TEST_FIASCOCONFIG</span></dt><dd><p class="startdd">Some userland tests rely on external information about the underlying platform and the configuration of the <a class="el" href="namespaceL4Re.html" title="L4Re C++ Interfaces.">L4Re</a> Microkernel to decide whether or not to test specific features or to determine which and how much resources are available. Some examples for this are whether or not virtualization is supported by the platform, how many cores the platform has, how many cores the kernel supports or how much memory the platform provides. To convey this information to these tests you can set the two environment variables <span class="tt">TEST_HWCONFIG</span> and <span class="tt">TEST_FIASCOCONFIG</span>.</p>
|
|
<p class="interdd">Using <span class="tt">TEST_HWCONFIG</span> requires a plain text document containing key-value pairs separated by a <span class="tt">=</span> symbol. On top of that comment lines starting with <span class="tt">#</span> are supported. Simply create a plain text file such as the following and set <span class="tt">TEST_HWCONFIG</span> to its absolute path. </p><pre class="fragment">VIRTUALIZATION=y
|
|
MP=y
|
|
NUM_CORES=4
|
|
MEMORY=2048
|
|
</pre><p class="interdd">Using <span class="tt">TEST_FIASCOCONFIG</span> is easier since it only needs to contain the absolute path of the globalconfig.out file in the <a class="el" href="namespaceL4Re.html" title="L4Re C++ Interfaces.">L4Re</a> Microkernel's build directory. The build system will then extract the information when a test is started.</p>
|
|
<p class="interdd">When starting a test the build system will read both files and provide their content as a lua table to the test. A ned script can then make decisions based on them. To simplify some decisions the build system merges some information by itself, e.g. virtualization is only available if both the platform and the <a class="el" href="namespaceL4Re.html" title="L4Re C++ Interfaces.">L4Re</a> Microkernel support this feature. More details can be obtain from the perl module in <span class="tt">tool/lib/L4/TestEnvLua.pm</span>.</p>
|
|
<p class="enddd"></p>
|
|
</dd></dl>
|
|
<p>In addition to these variables, the following BID variables can be overwritten at runtime: <span class="tt">PT</span> (for the plaform type) and <span class="tt">TEST_TIMEOUT</span>. You may also supply <span class="tt">QEMU_ARGS</span> and <span class="tt">MOE_ARGS</span> which will be appended to the parameters specified in the BID test make file.</p>
|
|
<p>Once the environment is set up, the tests can be run either by simply executing all of them from the build directory with </p><pre class="fragment">make test
|
|
</pre><p>or executing them directly, like </p><pre class="fragment">test/t/amd64_amdfam10/l4f/l4re-core/moe/test_namespace.t
|
|
</pre><p>or running one or more tests through the test harness <a href="http://perldoc.perl.org/prove.html">prove</a>, like </p><pre class="fragment">prove test/t/amd64_amdfam10/l4f/l4re-core/moe/test_namespace.t
|
|
prove -r test/t/amd64_amdfam10/l4f/l4re-core/
|
|
prove -rv test/t/amd64_amdfam10/l4f/l4re-core/
|
|
</pre><p>TEST_TAGS allow for a way to include or exclude whole groups of tests during execution, primarily with prove. You can specify which tests to run at runtime using one of the following ways: </p><pre class="fragment">$ test/t/amd64_amdfam10/l4f/l4re-core/test_one.t --run-tags slow,gtest-shuffle=0
|
|
$ test/t/amd64_amdfam10/l4f/l4re-core/test_one.t -T slow,gtest-shuffle=0
|
|
$ prove -r test/t/amd64_amdfam10/l4f/l4re-core/ :: -T slow,gtest-shuffle=0
|
|
$ TEST_RUN_TAGS=slow,gtest-shuffle=0 prove -r test/t/amd64_amdfam10/l4f/l4re-core/
|
|
</pre><p>For each test tag requirements defined in the corresponding TEST_TAGS Makefile variable are tested. If the requirements for tags do not match the test is skipped. The SKIP message will provide insight why the test was skipped: </p><pre class="fragment">$ make test
|
|
...
|
|
test/t/amd64_amdfam10/test_one.t .... ok
|
|
test/t/amd64_amdfam10/test_two.t .... skipped: Running this test requires tag slow to be set to 1.
|
|
test/t/amd64_amdfam10/test_three.t .. ok
|
|
</pre><p>When tags are provided, the tests requiring those tags are now also executed while the tests that forbid them are skipped: </p><pre class="fragment">$ TEST_RUN_TAGS=slow,gtest-shuffle
|
|
$ make test
|
|
...
|
|
test/t/amd64_amdfam10/test_one.t .... ok
|
|
test/t/amd64_amdfam10/test_two.t .... ok
|
|
test/t/amd64_amdfam10/test_three.t .. skipped: Running this test requires tag gtest-shuffle to be set to 0 or not specified.
|
|
</pre><p>For further details on how values in TEST_TAGS and TEST_RUN_TAGS interact, see the help text for TEST_TAGS.</p>
|
|
<h2>Running Tests in External Programs </h2>
|
|
<p>You can hand-over test execution to an external program by setting the environment variable <span class="tt">EXTERNAL_TEST_STARTER</span> to the full path of that program: </p><pre class="fragment">export EXTERNAL_TEST_STARTER=/path/to/external/test-starter
|
|
make test
|
|
</pre><dl class="section user"><dt><span class="tt">EXTERNAL_TEST_STARTER</span></dt><dd></dd></dl>
|
|
<p>This variable is evaluated by <span class="tt">tool/bin/run_test</span> (the backend behind <span class="tt">make test</span>) and contains the full path to the tool which actually starts the test instead of the test itself.</p>
|
|
<p>The <span class="tt">EXTERNAL_TEST_STARTER</span> can be any program instead of the default execution via <span class="tt">make qemu E=maketest</span>. Its output is taken by <span class="tt">run_test</span> as the test output.</p>
|
|
<p>Usually it is just a bridge to prepare the test execution, e.g., it could create the test as image and start that image via a simulator.</p>
|
|
<h3>Running Tests in a Simulator</h3>
|
|
<p>Based on above mechanism there is a dedicated external test starter <span class="tt">tool/bin/teststarter-image-telnet.pl</span> shipped in BID which assumes an image to be started with another program which provides test execution output on a network port.</p>
|
|
<p>This can be used to execute tests in a simulator, like this: </p><pre class="fragment">export EXTERNAL_TEST_STARTER=$L4RE_SRC/tool/bin/teststarter-image-telnet.pl
|
|
export SIMULATOR_START=/path/to/configured/simulator-exe
|
|
make test
|
|
</pre><p>After building the image and starting the simulator it contacts the simulator via a network port (sometimes called "telnet" port) to pass-through its execution output as its own output so it gets captured by <span class="tt">run_test</span> as usual.</p>
|
|
<p>The following variables control <span class="tt">teststarter-image-telnet.pl</span>:</p>
|
|
<dl class="section user"><dt><span class="tt">SIMULATOR_START</span></dt><dd>This points to the full path of the program that actually starts the prepared test image. Most often this is the frontend script of your simulator environment which is pre-configured so that it actually works in the way that <span class="tt">teststarter-image-telnet.pl</span> expects from the following settings.</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">SIMULATOR_IMAGETYPE</span></dt><dd>The image type to be generated via <span class="tt">make $SIMULATOR_IMAGETYPE
|
|
E=maketest</span>. Default is <span class="tt">elfimage</span>.</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">SIMULATOR_HOST</span></dt><dd>The simulator will be contacted via socket on that host to read its output. Default is <span class="tt">localhost</span>.</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">SIMULATOR_PORT</span></dt><dd>The simulator will be contacted via socket on that port to read its output. Default is <span class="tt">11111</span>.</dd></dl>
|
|
<dl class="section user"><dt><span class="tt">SIMULATOR_START_SLEEPTIME</span></dt><dd>After starting the simulator it waits that many seconds before reading from the port. Default is <span class="tt">1</span> (second).</dd></dl>
|
|
<h2>Running tests without tapper-wrapper </h2>
|
|
<p>In case you want to replace the tapper-wrapper test starter, you can replace the default one by setting the environment variable <span class="tt">TEST_STARTER</span> to the path of your test starter. Then your test starter can use the same environment which is normally set up for the default starter, which includes environment variables provided by the build system as well as the test itself. Among these are <span class="tt">SEARCHPATH</span>, <span class="tt">MODE</span>, <span class="tt">ARCH</span>, <span class="tt">MOE_CFG</span>, <span class="tt">MOE_ARGS</span>, <span class="tt">TEST_TIMEOUT</span>, <span class="tt">TEST_TARGET</span>, <span class="tt">TEST_EXPECTED</span>, <span class="tt">QEMU_ARGS</span> and many more.</p>
|
|
<h2>Debugging Tests </h2>
|
|
<p>The test script is only a thin wrapper that sets up the test environment as it was defined in the make file and then executes two scripts: <span class="tt">tapper-wrapper</span> and <span class="tt">run_test</span>.</p>
|
|
<p>The main work horse of the two is <span class="tt">tool/bin/run_test</span>. It collects the necessary files and starts qemu to execute the test. This script is always required.</p>
|
|
<p>There is then a second script wrapped around the test runner: <span class="tt">tool/bin/tapper-wrapper</span>. This tool inspects the output of the test runner and reformats it, so that it can be read by tools like <span class="tt">prove</span>. If the test produces tap output, then the script scans for this output and filters away all the debug output. If <span class="tt">TEST_EXPECTED</span> was defined, then the script scans the output for the expected lines and prints a suitable TAP message with success or failure. It also makes sure that qemu is killed as soon as the test is finished.</p>
|
|
<p>There are a number of command-line parameters that allow to quickly change test parameters for debugging purposes. Run the test with '–help' for more information about available parameters. </p>
|
|
</div></div><!-- contents -->
|
|
</div><!-- PageDoc -->
|
|
</div><!-- doc-content -->
|
|
<div id="page-nav" class="page-nav-panel">
|
|
<div id="page-nav-resize-handle"></div>
|
|
<div id="page-nav-tree">
|
|
<div id="page-nav-contents">
|
|
</div><!-- page-nav-contents -->
|
|
</div><!-- page-nav-tree -->
|
|
</div><!-- page-nav -->
|
|
</div><!-- container -->
|
|
<!-- HTML footer for doxygen 1.9.1-->
|
|
<!-- start footer part -->
|
|
<div id="nav-path" class="navpath"><!-- id is needed for treeview function! -->
|
|
<ul>
|
|
<li class="navelem"><a href="l4re_concepts.html">Programming for L4Re</a></li><li class="navelem"><a href="l4re_build_system.html">L4Re Build System</a></li>
|
|
<li class="footer">Generated on <span class="timestamp"></span> for L4Re Operating System Framework by <a href="https://www.doxygen.org/index.html"><img class="footer" src="doxygen.svg" width="104" height="31" alt="doxygen"/></a> 1.15.0 </li>
|
|
</ul>
|
|
</div>
|
|
</body>
|
|
</html>
|