mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-05-09 17:39:31 +00:00
Code Issues 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
documentation/test-manual/test-manual-intro.xml
+34 -45
View File
@@ -214,52 +214,41 @@
Tests map into the codebase as follows: Tests map into the codebase as follows:
<itemizedlist> <itemizedlist>
<listitem><para> <listitem><para>
<emphasis>bitbake-selftest</emphasis>: <itemizedlist> <emphasis>bitbake-selftest</emphasis>: </para>
<listitem> <para>These tests are self-contained and test BitBake as well as its APIs, which
<para>These tests are self-contained and test BitBake as well as its include the fetchers. The tests are located in
APIs, which include the fetchers. The tests are located in <filename>bitbake/lib/*/tests</filename>. </para>
<filename>bitbake/lib/*/tests</filename>. </para> <para>From within the BitBake repository, run the following:
</listitem> <literallayout class="monospaced">
<listitem>
<para>From within the BitBake repository, run the following:
<literallayout class="monospaced">
$ bitbake-selftest $ bitbake-selftest
</literallayout> </literallayout>
</para> </para>
</listitem> <para>To skip tests that access the Internet, use the
<listitem> <filename>BB_SKIP_NETTEST</filename> variable when running
<para>To skip tests that access the Internet, use the "bitbake-selftest" as follows:
<filename>BB_SKIP_NETTEST</filename> variable when running <literallayout class="monospaced">
"bitbake-selftest" as follows:
<literallayout class="monospaced">
$ BB_SKIP_NETTEST=yes bitbake-selftest $ BB_SKIP_NETTEST=yes bitbake-selftest
</literallayout>The </literallayout></para>
default output is quiet and just prints a summary of what was <para>The default output is quiet and just prints a summary of what was run. To
run. To see more information, there is a verbose see more information, there is a verbose
option:<literallayout> option:<literallayout class="monospaced">
$ bitbake-selftest -v $ bitbake-selftest -v
</literallayout></para> </literallayout></para>
<para>Use this option when you wish to skip tests that access the <para>Use this option when you wish to skip tests that access the network, which
network, which are mostly necessary to test the fetcher modules. are mostly necessary to test the fetcher modules. To specify individual test
To specify individual test modules to run, append the test modules to run, append the test module name to the "bitbake-selftest"
module name to the "bitbake-selftest" command. For example, to command. For example, to specify the tests for the bb.data.module, run:
specify the tests for the bb.data.module, run: <literallayout class="monospaced">
<literallayout class="monospaced">
$ bitbake-selftest bb.test.data.module $ bitbake-selftest bb.test.data.module
</literallayout>You </literallayout>You
can also specify individual tests by defining the full name and can also specify individual tests by defining the full name and module plus
module plus the class path of the test, for example: the class path of the test, for example:
<literallayout> <literallayout class="monospaced">
$ bitbake-selftest bb.tests.data.TestOverrides.test_one_override $ bitbake-selftest bb.tests.data.TestOverrides.test_one_override
</literallayout></para> </literallayout></para>
</listitem> <para>The tests are based on <ulink
<listitem> url="https://docs.python.org/3/library/unittest.html">Python
<para>The tests are based on <ulink unittest</ulink>. </para></listitem>
url="https://docs.python.org/3/library/unittest.html">Python
unittest</ulink>. </para>
</listitem>
</itemizedlist>
</para></listitem>
<listitem><para> <listitem><para>
<emphasis>oe-selftest</emphasis>: <itemizedlist> <emphasis>oe-selftest</emphasis>: <itemizedlist>
<listitem> <listitem>
@@ -297,12 +286,12 @@
</literallayout> </literallayout>
For example, the following command would run the tinfoil getVar For example, the following command would run the tinfoil getVar
API API
test:<literallayout> test:<literallayout class="monospaced">
$ oe-selftest -r tinfoil.TinfoilTests.test_getvar $ oe-selftest -r tinfoil.TinfoilTests.test_getvar
</literallayout>It </literallayout>It
is also possible to run a set of tests. For example the is also possible to run a set of tests. For example the
following command will run all of the tinfoil following command will run all of the tinfoil
tests:<literallayout> tests:<literallayout class="monospaced">
$ oe-selftest -r tinfoil $ oe-selftest -r tinfoil
</literallayout></para> </literallayout></para>
</listitem> </listitem>
@@ -408,7 +397,7 @@
<title><filename>bitbake-selftest</filename></title> <title><filename>bitbake-selftest</filename></title>
<para>A simple test example from <filename>lib/bb/tests/data.py</filename> is: <para>A simple test example from <filename>lib/bb/tests/data.py</filename> is:
<literallayout> <literallayout class="monospaced">
class DataExpansions(unittest.TestCase): class DataExpansions(unittest.TestCase):
def setUp(self): def setUp(self):
self.d = bb.data.init() self.d = bb.data.init()
@@ -438,7 +427,7 @@
builds. Rather than directly using Python's unittest, the code wraps most of the 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 standard objects. The tests can be simple, such as testing a command from within the
OE build environment using the following OE build environment using the following
example:<literallayout> example:<literallayout class="monospaced">
class BitbakeLayers(OESelftestTestCase): class BitbakeLayers(OESelftestTestCase):
def test_bitbakelayers_showcrossdepends(self): def test_bitbakelayers_showcrossdepends(self):
result = runCmd('bitbake-layers show-cross-depends') 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 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 environment, as opposed to a host build environment. A simple example from
<filename>meta/lib/oeqa/runtime/cases/python.py</filename> contains the <filename>meta/lib/oeqa/runtime/cases/python.py</filename> contains the
following:<literallayout> following:<literallayout class="monospaced">
class PythonTest(OERuntimeTestCase): class PythonTest(OERuntimeTestCase):
@OETestDepends(['ssh.SSHTest.test_ssh']) @OETestDepends(['ssh.SSHTest.test_ssh'])
@OEHasPackage(['python3-core']) @OEHasPackage(['python3-core'])
@@ -514,7 +503,7 @@
<para>These tests are run against built extensible SDKs (eSDKs). The tests can assume <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 that the eSDK environment has already been setup. An example from
<filename>meta/lib/oeqa/sdk/cases/devtool.py</filename> contains the <filename>meta/lib/oeqa/sdk/cases/devtool.py</filename> contains the
following:<literallayout> following:<literallayout class="monospaced">
class DevtoolTest(OESDKExtTestCase): class DevtoolTest(OESDKExtTestCase):
@classmethod @classmethod
def setUpClass(cls): def setUpClass(cls):
@@ -548,7 +537,7 @@
<para>These tests are run against built SDKs. The tests can assume that an SDK has <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 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 from <filename>meta/lib/oeqa/sdk/cases/python2.py</filename> contains the
following:<literallayout> following:<literallayout class="monospaced">
class Python3Test(OESDKTestCase): class Python3Test(OESDKTestCase):
def setUp(self): def setUp(self):
if not (self.tc.hasHostPackage("nativesdk-python3-core") or 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 <para>The performance tests usually measure how long operations take and the resource
utilisation as that happens. An example from utilisation as that happens. An example from
<filename>meta/lib/oeqa/buildperf/test_basic.py</filename> contains the <filename>meta/lib/oeqa/buildperf/test_basic.py</filename> contains the
following:<literallayout> following:<literallayout class="monospaced">
class Test3(BuildPerfTestCase): class Test3(BuildPerfTestCase):
def test3(self): def test3(self):
documentation/test-manual/test-manual-understand-autobuilder.xml
+11 -10
View File
@@ -20,7 +20,7 @@
<filename>config.json</filename> file within the <filename>config.json</filename> file within the
<filename>yocto-autobuilder-helper</filename> repository. The targets are defined in <filename>yocto-autobuilder-helper</filename> repository. The targets are defined in
the ‘overrides’ section, a quick example could be qemux86-64 which looks the ‘overrides’ section, a quick example could be qemux86-64 which looks
like:<literallayout> like:<literallayout class="monospaced">
"qemux86-64" : { "qemux86-64" : {
"MACHINE" : "qemux86-64", "MACHINE" : "qemux86-64",
"TEMPLATE" : "arch-qemu", "TEMPLATE" : "arch-qemu",
@@ -32,7 +32,7 @@
}, },
</literallayout>And </literallayout>And
to expand that, you need the “arch-qemu” entry from the “templates” section, which looks to expand that, you need the “arch-qemu” entry from the “templates” section, which looks
like:<literallayout> like:<literallayout class="monospaced">
"arch-qemu" : { "arch-qemu" : {
"BUILDINFO" : true, "BUILDINFO" : true,
"BUILDHISTORY" : true, "BUILDHISTORY" : true,
@@ -52,11 +52,12 @@
} }
}, },
</literallayout>Combining </literallayout>Combining
these two entries you can see that “qemux86-64” is a three step build where the “bitbake these two entries you can see that “qemux86-64” is a three step build where the
BBTARGETS” would be run, then “bitbake SANITYTARGETS” for each step; all for <filename>bitbake BBTARGETS</filename> would be run, then <filename>bitbake
MACHINE=”qemx86-64” but with differing SDKMACHINE settings. In step 1 an extra variable SANITYTARGETS</filename> for each step; all for
is added to the <filename>auto.conf</filename> file to enable wic image <filename>MACHINE=”qemx86-64”</filename> but with differing SDKMACHINE settings. In
generation.</para> 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 <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 mechanism allows quite complex configurations to be built up yet allows duplication and
repetition to be kept to a minimum.</para> repetition to be kept to a minimum.</para>
@@ -284,18 +285,18 @@
substitution of the paths. The Helper script repository includes a substitution of the paths. The Helper script repository includes a
<filename>local-example.json</filename> file to show how you could override these <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 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" $ ABHELPER_JSON="config.json local-example.json"
</literallayout>As </literallayout>As
another example, you could also pass the following into the 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" $ ABHELPER_JSON="config.json <replaceable>/some/location/</replaceable>local.json"
</literallayout>One </literallayout>One
issue users often run into is validation of the <filename>config.json</filename> files. 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 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 <filename>pre-commit-hook.sh</filename> script to verify the JSON file before
committing it. Create a symbolic link as committing it. Create a symbolic link as
follows:<literallayout> follows:<literallayout class="monospaced">
$ ln -s ../../scripts/pre-commit-hook.sh .git/hooks/pre-commit $ ln -s ../../scripts/pre-commit-hook.sh .git/hooks/pre-commit
</literallayout></para> </literallayout></para>
</section> </section>