Merge pull request #8287 from svenstaro/patch-1

Few language fixes for docs

docsite/rst/test_strategies.rst

@@ -10,18 +10,18 @@ Many times, people ask, "how can I best integrate testing with Ansible playbooks
 to be a "fail-fast" and ordered system, therefore it makes it easy to embed testing directly in Ansible playbooks.  In this chapter,
 we'll go into some patterns for integrating tests of infrastructure and discuss the right level of testing that may be appropriate.
 
-.. note:: This is a chapter about testing the application you are deploying, not the chapter on how to test ansible modules during development.  For that content, please hop over to the Development section.
+.. note:: This is a chapter about testing the application you are deploying, not the chapter on how to test Ansible modules during development.  For that content, please hop over to the Development section.
 
-By incorporating a degree of testing into your deployment workflow, there will be less surprises when code hits production, and in many cases,
-tests can be leveraged in production to prevent failed updates from migrating across an entire installation.  Since it's push-based and
-also makes it very easy to run steps on the localhost or testing servers, Ansible lets you insert as many checks and balances into your upgrade workflow as you would like to insert.
+By incorporating a degree of testing into your deployment workflow, there will be fewer surprises when code hits production and, in many cases,
+tests can be leveraged in production to prevent failed updates from migrating across an entire installation.  Since it's push-based, it's
+also very easy to run the steps on thelocalhost or testing servers. Ansible lets you insert as many checks and balances into your upgrade workflow as you would like to have.
 
 The Right Level of Testing
 ``````````````````````````
 
 Ansible resources are models of desired-state.  As such, it should not be neccessary to test that services are running, packages are
 installed, or other such things.  Ansible is the system that will ensure these things are declaratively true.   Instead, assert these
-things into your playbooks.
+things in your playbooks.
 
 .. code-block:: yaml
 
@@ -35,7 +35,9 @@ do later).
 Check Mode As A Drift Test
 ``````````````````````````
 
-In the above setup, `--check` mode in Ansible can be used as a layer of testing as well.  If running a deployment playbook against an existing system, using the `--check` flag to the ansible command will report if Ansible thinks it would have had to have made any changes to bring the system into a desired state.
+In the above setup, `--check` mode in Ansible can be used as a layer of testing as well.  If running a deployment playbook against an
+existing system, using the `--check` flag to the `ansible` command will report if Ansible thinks it would have had to have made any changes to
+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 always execute in check mode, such as calls to the script module, add the 'always_run' flag::
@@ -77,7 +79,7 @@ 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 easily to validate various kinds of truth::
+And the assert module makes it very easy to validate various kinds of truth::
 
    tasks:
 
@@ -89,7 +91,7 @@ And the assert module makes it very easily 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 existance 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 existance of files that are not declaratively set by your Ansible configuration, the 'stat' module is a great choice::
 
    tasks:
 
@@ -123,7 +125,7 @@ Your workflow may be something like this::
     - Deploy to production, with the same integrated tests.
 
 Something like an integration test battery should be written by your QA team if you are a production webservice.  This would include
-things like Selenium tests or automated API tests and would usually not be something embedded into your ansible playbooks.
+things like Selenium tests or automated API tests and would usually not be something embedded into your Ansible playbooks.
 
 However, it does make sense to include some basic health checks into your playbooks, and in some cases it may be possible to run
 a subset of the QA battery against remote nodes.   This is what the next section covers.
@@ -226,15 +228,15 @@ Conclusion
 ``````````
 
 Ansible believes you should not need another framework to validate basic things of your infrastructure is true.  This is the case
-because ansible is an order-based system that will fail immediately on unhandled errors for a host, and prevent further configuration
+because Ansible is an order-based system that will fail immediately on unhandled errors for a host, and prevent further configuration
 of that host.  This forces errors to the top and shows them in a summary at the end of the Ansible run.
 
 However, as Ansible is designed as a multi-tier orchestration system, it makes it very easy to incorporate tests into the end of
 a playbook run, either using loose tasks or roles.  When used with rolling updates, testing steps can decide whether to put a machine
 back into a load balanced pool or not.
 
-Finally, because Ansible errors propogate all the way up to the return code of the ansible program itself, and Ansible by default
-runs in an easy push-based mode, ansible is a great step to put into a build environment if you wish to use it to roll out systems
+Finally, because Ansible errors propogate all the way up to the return code of the Ansible program itself, and Ansible by default
+runs in an easy push-based mode, Ansible is a great step to put into a build environment if you wish to use it to roll out systems
 as part of a Continous Integration/Continous Delivery pipeline, as is covered in sections above.
 
 The focus should not be on infrastructure testing, but on application testing, so we strongly encourage getting together with your