test-manual: Fixed codeblock formatting

(From yocto-docs rev: f9df2c8f68ba5732a2d83c99d2b9597ef66dc378)

Signed-off-by: Mark Morton <mark.morton@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

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:
             <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):
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 @@
                 <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>