mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-04-03 20:02:24 +02:00
Code Issues Packages Projects Releases Wiki Activity

test-manual: Fixed codeblock formatting

Browse Source 
(From yocto-docs rev: f9df2c8f68ba5732a2d83c99d2b9597ef66dc378)

Signed-off-by: Mark Morton <mark.morton@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Mark Morton
2020-06-16 16:03:34 -07:00
committed by Richard Purdie
parent 2bd173f3b5
commit 5534f6d0a2
2 changed files with 45 additions and 55 deletions
Download Patch File Download Diff File Expand all files Collapse all files

79
documentation/test-manual/test-manual-intro.xml
View File

@@ -214,52 +214,41 @@
Tests map into the codebase as follows:
<itemizedlist>
<listitem><para>
<emphasis>bitbake-selftest</emphasis>: <itemizedlist>
<listitem>
<para>These tests are self-contained and test BitBake as well as its
APIs, which include the fetchers. The tests are located in
<filename>bitbake/lib/*/tests</filename>. </para>
</listitem>
<listitem>
<para>From within the BitBake repository, run the following:
<literallayout class="monospaced">
<emphasis>bitbake-selftest</emphasis>: </para>
<para>These tests are self-contained and test BitBake as well as its APIs, which
include the fetchers. The tests are located in
<filename>bitbake/lib/*/tests</filename>. </para>
<para>From within the BitBake repository, run the following:
<literallayout class="monospaced">
$ bitbake-selftest
</literallayout>
</para>
</listitem>
<listitem>
<para>To skip tests that access the Internet, use the
<filename>BB_SKIP_NETTEST</filename> variable when running
"bitbake-selftest" as follows:
<literallayout class="monospaced">
</para>
<para>To skip tests that access the Internet, use the
<filename>BB_SKIP_NETTEST</filename> variable when running
"bitbake-selftest" as follows:
<literallayout class="monospaced">
$ BB_SKIP_NETTEST=yes bitbake-selftest
</literallayout>The
default output is quiet and just prints a summary of what was
run. To see more information, there is a verbose
option:<literallayout>
</literallayout></para>
<para>The default output is quiet and just prints a summary of what was run. To
see more information, there is a verbose
option:<literallayout class="monospaced">
$ bitbake-selftest -v
</literallayout></para>
<para>Use this option when you wish to skip tests that access the
network, which are mostly necessary to test the fetcher modules.
To specify individual test modules to run, append the test
module name to the "bitbake-selftest" command. For example, to
specify the tests for the bb.data.module, run:
<literallayout class="monospaced">
<para>Use this option when you wish to skip tests that access the network, which
are mostly necessary to test the fetcher modules. To specify individual test
modules to run, append the test module name to the "bitbake-selftest"
command. For example, to specify the tests for the bb.data.module, run:
<literallayout class="monospaced">
$ bitbake-selftest bb.test.data.module
</literallayout>You
can also specify individual tests by defining the full name and
module plus the class path of the test, for example:
<literallayout>
can also specify individual tests by defining the full name and module plus
the class path of the test, for example:
<literallayout class="monospaced">
$ bitbake-selftest bb.tests.data.TestOverrides.test_one_override
</literallayout></para>
</listitem>
<listitem>
<para>The tests are based on <ulink
url="https://docs.python.org/3/library/unittest.html">Python
unittest</ulink>. </para>
</listitem>
</itemizedlist>
</para></listitem>
<para>The tests are based on <ulink
url="https://docs.python.org/3/library/unittest.html">Python
unittest</ulink>. </para></listitem>
<listitem><para>
<emphasis>oe-selftest</emphasis>: <itemizedlist>
<listitem>
@@ -297,12 +286,12 @@
</literallayout>
For example, the following command would run the tinfoil getVar
API
test:<literallayout>
test:<literallayout class="monospaced">
$ oe-selftest -r tinfoil.TinfoilTests.test_getvar
</literallayout>It
is also possible to run a set of tests. For example the
following command will run all of the tinfoil
tests:<literallayout>
tests:<literallayout class="monospaced">
$ oe-selftest -r tinfoil
</literallayout></para>
</listitem>
@@ -408,7 +397,7 @@
<title><filename>bitbake-selftest</filename></title>
<para>A simple test example from <filename>lib/bb/tests/data.py</filename> is:
<literallayout>
<literallayout class="monospaced">
class DataExpansions(unittest.TestCase):
def setUp(self):
self.d = bb.data.init()
@@ -438,7 +427,7 @@
builds. Rather than directly using Python's unittest, the code wraps most of the
standard objects. The tests can be simple, such as testing a command from within the
OE build environment using the following
example:<literallayout>
example:<literallayout class="monospaced">
class BitbakeLayers(OESelftestTestCase):
def test_bitbakelayers_showcrossdepends(self):
result = runCmd('bitbake-layers show-cross-depends')
@@ -487,7 +476,7 @@
under QEMU. As a result, they are assumed to be running in a target image
environment, as opposed to a host build environment. A simple example from
<filename>meta/lib/oeqa/runtime/cases/python.py</filename> contains the
following:<literallayout>
following:<literallayout class="monospaced">
class PythonTest(OERuntimeTestCase):
@OETestDepends(['ssh.SSHTest.test_ssh'])
@OEHasPackage(['python3-core'])
@@ -514,7 +503,7 @@
<para>These tests are run against built extensible SDKs (eSDKs). The tests can assume
that the eSDK environment has already been setup. An example from
<filename>meta/lib/oeqa/sdk/cases/devtool.py</filename> contains the
following:<literallayout>
following:<literallayout class="monospaced">
class DevtoolTest(OESDKExtTestCase):
@classmethod
def setUpClass(cls):
@@ -548,7 +537,7 @@
<para>These tests are run against built SDKs. The tests can assume that an SDK has
already been extracted and its environment file has been sourced. A simple example
from <filename>meta/lib/oeqa/sdk/cases/python2.py</filename> contains the
following:<literallayout>
following:<literallayout class="monospaced">
class Python3Test(OESDKTestCase):
def setUp(self):
if not (self.tc.hasHostPackage("nativesdk-python3-core") or
@@ -571,7 +560,7 @@
<para>The performance tests usually measure how long operations take and the resource
utilisation as that happens. An example from
<filename>meta/lib/oeqa/buildperf/test_basic.py</filename> contains the
following:<literallayout>
following:<literallayout class="monospaced">
class Test3(BuildPerfTestCase):
def test3(self):

21
documentation/test-manual/test-manual-understand-autobuilder.xml
View File

@@ -20,7 +20,7 @@
<filename>config.json</filename> file within the
<filename>yocto-autobuilder-helper</filename> repository. The targets are defined in
the ‘overrides’ section, a quick example could be qemux86-64 which looks
like:<literallayout>
like:<literallayout class="monospaced">
"qemux86-64" : {
"MACHINE" : "qemux86-64",
"TEMPLATE" : "arch-qemu",
@@ -32,7 +32,7 @@
},
</literallayout>And
to expand that, you need the “arch-qemu” entry from the “templates” section, which looks
like:<literallayout>
like:<literallayout class="monospaced">
"arch-qemu" : {
"BUILDINFO" : true,
"BUILDHISTORY" : true,
@@ -52,11 +52,12 @@
}
},
</literallayout>Combining
these two entries you can see that “qemux86-64” is a three step build where the “bitbake
BBTARGETS” would be run, then “bitbake SANITYTARGETS” for each step; all for
MACHINE=”qemx86-64” but with differing SDKMACHINE settings. In step 1 an extra variable
is added to the <filename>auto.conf</filename> file to enable wic image
generation.</para>
these two entries you can see that “qemux86-64” is a three step build where the
<filename>bitbake BBTARGETS</filename> would be run, then <filename>bitbake
SANITYTARGETS</filename> for each step; all for
<filename>MACHINE=”qemx86-64”</filename> but with differing SDKMACHINE settings. In
step 1 an extra variable is added to the <filename>auto.conf</filename> file to enable
wic image generation.</para>
<para>While not every detail of this is covered here, you can see how the templating
mechanism allows quite complex configurations to be built up yet allows duplication and
repetition to be kept to a minimum.</para>
@@ -284,18 +285,18 @@
substitution of the paths. The Helper script repository includes a
<filename>local-example.json</filename> file to show how you could override these
from a separate configuration file. Pass the following into the environment of the
Autobuilder:<literallayout>
Autobuilder:<literallayout class="monospaced">
$ ABHELPER_JSON="config.json local-example.json"
</literallayout>As
another example, you could also pass the following into the
environment:<literallayout>
environment:<literallayout class="monospaced">
$ ABHELPER_JSON="config.json <replaceable>/some/location/</replaceable>local.json"
</literallayout>One
issue users often run into is validation of the <filename>config.json</filename> files.
A tip for minimizing issues from invalid json files is to use a Git
<filename>pre-commit-hook.sh</filename> script to verify the JSON file before
committing it. Create a symbolic link as
follows:<literallayout>
follows:<literallayout class="monospaced">
$ ln -s ../../scripts/pre-commit-hook.sh .git/hooks/pre-commit
</literallayout></para>
</section>