Cleaned up test_strategies doc (#79045)

Authored-by: Shade Alabsa <shadealabsa@microsoft.com>

docs/docsite/rst/reference_appendices/test_strategies.rst

@@ -47,7 +47,9 @@ existing system, using the ``--check`` flag to the `ansible` command will report
 bring the system into a desired state.
 
 This can let you know up front if there is any need to deploy onto the given system.  Ordinarily, scripts and commands don't run in check mode, so if you
-want certain steps to execute in normal mode even when the ``--check`` flag is used, such as calls to the script module, disable check mode for those tasks::
+want certain steps to execute in normal mode even when the ``--check`` flag is used, such as calls to the script module, disable check mode for those tasks:
+
+.. code:: yaml
 
 
    roles:
@@ -60,7 +62,9 @@ want certain steps to execute in normal mode even when the ``--check`` flag is u
 Modules That Are Useful for Testing
 ```````````````````````````````````
 
-Certain playbook modules are particularly good for testing.  Below is an example that ensures a port is open::
+Certain playbook modules are particularly good for testing.  Below is an example that ensures a port is open:
+
+.. code:: yaml
 
    tasks:
 
@@ -69,7 +73,9 @@ Certain playbook modules are particularly good for testing.  Below is an example
          port: 22
        delegate_to: localhost
       
-Here's an example of using the URI module to make sure a web service returns::
+Here's an example of using the URI module to make sure a web service returns:
+
+.. code:: yaml
 
    tasks:
 
@@ -80,7 +86,9 @@ Here's an example of using the URI module to make sure a web service returns::
          msg: 'service is not happy'
        when: "'AWESOME' not in webpage.content"
 
-It's easy to push an arbitrary script (in any language) on a remote host and the script will automatically fail if it has a non-zero return code::
+It's easy to push an arbitrary script (in any language) on a remote host and the script will automatically fail if it has a non-zero return code:
+
+.. code:: yaml
 
    tasks:
 
@@ -89,7 +97,9 @@ It's easy to push an arbitrary script (in any language) on a remote host and the
 
 If using roles (you should be, roles are great!), scripts pushed by the script module can live in the 'files/' directory of a role.
 
-And the assert module makes it very easy to validate various kinds of truth::
+And the assert module makes it very easy to validate various kinds of truth:
+
+.. code:: yaml
 
    tasks:
 
@@ -101,7 +111,9 @@ And the assert module makes it very easy to validate various kinds of truth::
             - "'not ready' not in cmd_result.stderr"
             - "'gizmo enabled' in cmd_result.stdout"
 
-Should you feel the need to test for the existence of files that are not declaratively set by your Ansible configuration, the 'stat' module is a great choice::
+Should you feel the need to test for the existence of files that are not declaratively set by your Ansible configuration, the 'stat' module is a great choice:
+
+.. code:: yaml
 
    tasks:
 
@@ -128,7 +140,9 @@ If writing some degree of basic validation of your application into your playboo
 As such, deploying into a local development VM and a staging environment will both validate that things are according to plan
 ahead of your production deploy.
 
-Your workflow may be something like this::
+Your workflow may be something like this:
+
+.. code:: text
 
     - Use the same playbook all the time with embedded tests in development
     - Use the playbook to deploy to a staging environment (with the same playbooks) that simulates production
@@ -147,7 +161,9 @@ Integrating Testing With Rolling Updates
 If you have read into :ref:`playbooks_delegation` it may quickly become apparent that the rolling update pattern can be extended, and you
 can use the success or failure of the playbook run to decide whether to add a machine into a load balancer or not. 
 
-This is the great culmination of embedded tests::
+This is the great culmination of embedded tests:
+
+.. code:: yaml
 
     ---
 
@@ -182,7 +198,9 @@ the machine will not go back into the pool.
 Read the delegation chapter about "max_fail_percentage" and you can also control how many failing tests will stop a rolling update
 from proceeding.
 
-This above approach can also be modified to run a step from a testing machine remotely against a machine::
+This above approach can also be modified to run a step from a testing machine remotely against a machine:
+
+.. code:: yaml
 
     ---
 
@@ -221,7 +239,9 @@ Achieving Continuous Deployment
 
 If desired, the above techniques may be extended to enable continuous deployment practices.
 
-The workflow may look like this::
+The workflow may look like this:
+
+.. code:: text
 
     - Write and use automation to deploy local development VMs
     - Have a CI system like Jenkins deploy to a staging environment on every code change