From 5534f6d0a2fdc42e4dc0046eee2389cd1c95010b Mon Sep 17 00:00:00 2001 From: Mark Morton Date: Tue, 16 Jun 2020 16:03:34 -0700 Subject: test-manual: Fixed codeblock formatting (From yocto-docs rev: f9df2c8f68ba5732a2d83c99d2b9597ef66dc378) Signed-off-by: Mark Morton Signed-off-by: Richard Purdie --- documentation/test-manual/test-manual-intro.xml | 79 ++++++++++------------ .../test-manual-understand-autobuilder.xml | 21 +++--- 2 files changed, 45 insertions(+), 55 deletions(-) diff --git a/documentation/test-manual/test-manual-intro.xml b/documentation/test-manual/test-manual-intro.xml index 9464d332c2..8e2c7cd874 100644 --- a/documentation/test-manual/test-manual-intro.xml +++ b/documentation/test-manual/test-manual-intro.xml @@ -214,52 +214,41 @@ Tests map into the codebase as follows: - bitbake-selftest: - - These tests are self-contained and test BitBake as well as its - APIs, which include the fetchers. The tests are located in - bitbake/lib/*/tests. - - - From within the BitBake repository, run the following: - + bitbake-selftest: + These tests are self-contained and test BitBake as well as its APIs, which + include the fetchers. The tests are located in + bitbake/lib/*/tests. + From within the BitBake repository, run the following: + $ bitbake-selftest - - - - To skip tests that access the Internet, use the - BB_SKIP_NETTEST variable when running - "bitbake-selftest" as follows: - + + To skip tests that access the Internet, use the + BB_SKIP_NETTEST variable when running + "bitbake-selftest" as follows: + $ BB_SKIP_NETTEST=yes bitbake-selftest - The - default output is quiet and just prints a summary of what was - run. To see more information, there is a verbose - option: + + The default output is quiet and just prints a summary of what was run. To + see more information, there is a verbose + option: $ bitbake-selftest -v - 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: - + 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: + $ bitbake-selftest bb.test.data.module You - can also specify individual tests by defining the full name and - module plus the class path of the test, for example: - + can also specify individual tests by defining the full name and module plus + the class path of the test, for example: + $ bitbake-selftest bb.tests.data.TestOverrides.test_one_override - - - The tests are based on Python - unittest. - - - + The tests are based on Python + unittest. oe-selftest: @@ -297,12 +286,12 @@ For example, the following command would run the tinfoil getVar API - test: + test: $ oe-selftest -r tinfoil.TinfoilTests.test_getvar It is also possible to run a set of tests. For example the following command will run all of the tinfoil - tests: + tests: $ oe-selftest -r tinfoil @@ -408,7 +397,7 @@ <filename>bitbake-selftest</filename> A simple test example from lib/bb/tests/data.py is: - + 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: + example: 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 meta/lib/oeqa/runtime/cases/python.py contains the - following: + following: class PythonTest(OERuntimeTestCase): @OETestDepends(['ssh.SSHTest.test_ssh']) @OEHasPackage(['python3-core']) @@ -514,7 +503,7 @@ These tests are run against built extensible SDKs (eSDKs). The tests can assume that the eSDK environment has already been setup. An example from meta/lib/oeqa/sdk/cases/devtool.py contains the - following: + following: class DevtoolTest(OESDKExtTestCase): @classmethod def setUpClass(cls): @@ -548,7 +537,7 @@ 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 meta/lib/oeqa/sdk/cases/python2.py contains the - following: + following: class Python3Test(OESDKTestCase): def setUp(self): if not (self.tc.hasHostPackage("nativesdk-python3-core") or @@ -571,7 +560,7 @@ The performance tests usually measure how long operations take and the resource utilisation as that happens. An example from meta/lib/oeqa/buildperf/test_basic.py contains the - following: + following: class Test3(BuildPerfTestCase): def test3(self): diff --git a/documentation/test-manual/test-manual-understand-autobuilder.xml b/documentation/test-manual/test-manual-understand-autobuilder.xml index c96713c1dc..a04006605f 100644 --- a/documentation/test-manual/test-manual-understand-autobuilder.xml +++ b/documentation/test-manual/test-manual-understand-autobuilder.xml @@ -20,7 +20,7 @@ config.json file within the yocto-autobuilder-helper repository. The targets are defined in the ‘overrides’ section, a quick example could be qemux86-64 which looks - like: + like: "qemux86-64" : { "MACHINE" : "qemux86-64", "TEMPLATE" : "arch-qemu", @@ -32,7 +32,7 @@ }, And to expand that, you need the “arch-qemu” entry from the “templates” section, which looks - like: + like: "arch-qemu" : { "BUILDINFO" : true, "BUILDHISTORY" : true, @@ -52,11 +52,12 @@ } }, 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 auto.conf file to enable wic image - generation. + 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 auto.conf file to enable + wic image generation. 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. @@ -284,18 +285,18 @@ substitution of the paths. The Helper script repository includes a local-example.json file to show how you could override these from a separate configuration file. Pass the following into the environment of the - Autobuilder: + Autobuilder: $ ABHELPER_JSON="config.json local-example.json" As another example, you could also pass the following into the - environment: + environment: $ ABHELPER_JSON="config.json /some/location/local.json" One issue users often run into is validation of the config.json files. A tip for minimizing issues from invalid json files is to use a Git pre-commit-hook.sh script to verify the JSON file before committing it. Create a symbolic link as - follows: + follows: $ ln -s ../../scripts/pre-commit-hook.sh .git/hooks/pre-commit -- cgit v1.2.3-54-g00ecf