docs: apply some bugfixes from master to writing-tests.adoc

Author: SebKuzminsky

docs/src/code/writing-tests.adoc

@@ -4,9 +4,9 @@
 == The test framework
 
 The code base has unit and integration tests that can be executed
-automatically to ensure the program work as intended.  Such tests are
+automatically to ensure the program works as intended.  Such tests are
 often written to trigger a bug and to ensure the bug is detected if it
-resurface in the future, but also to validate behavior of components
+resurfaces in the future, but also to validate behavior of components
 and interfaces.
 
 The tests are collected in the `tests/` directory.  The individual tests
@@ -34,7 +34,7 @@ _test.hal_ below the directories specified on the command line, or under
 `tests/` if no command line argument is specified. These files
 represent three different ways to run the tests.
 
-The _runtests_ script accept the following arguments, see the output
+The _runtests_ script accepts the following arguments, see the output
 from `scripts/runtests -h` for the authorative list:
 ----
 -n  do not remove temporary files for successful tests.
@@ -59,23 +59,23 @@ tests:
 .Test script (only one of these three)
 
 test::
-   A program executed and its exit code and output is checked using
+   A program that is executed and its exit code and output checked using
    either checkresult or expected.
 
 test.sh::
-   A bash script executed and its exit code and output is checked using
+   A bash script that is executed and its exit code and output checked using
    either checkresult or expected.
 
 test.hal::
-   A HAL script executed using `halrun -f test.hal` and its exit code
-   and output is checked using either checkresult or expected.
+   A HAL script that is executed using `halrun -f test.hal` and its exit code
+   and output checked using either checkresult or expected.
 
 .Test evaluation
 
  expected::
-   A file whos content is compared to the output from running the test
+   A file whose content is compared to the output from running the test
    scripts.  If the test output is identical to the content of the
-   expected file, the test succeed.
+   expected file, the test succeeds.
 
 checkresult::
    An excutable file to perform more complex validation than just comparing
@@ -85,7 +85,7 @@ checkresult::
    is consulted to validate the test output.
 
  xfail::
-   If this file exist, a test failure is expected and do not cause
+   If this file exist, a test failure is expected and does not cause
    runtests to return an exit code signaling an error.
 
  skip::
@@ -94,20 +94,20 @@ checkresult::
  control::
    This file can be used to flag specific needs in the test.  At the
    moment, the use of _sudo_ can be flagged, and tests requiring sudo
-   can be skipped when using `runtests -u`. To flag such requirement,
+   can be skipped when using `runtests -u`. To flag such requirements,
    add a line with `Restrictions: sudo` to this file.
 
 == Some testing approaches
 
-There are various ways to structure a test, depending on what one want
+There are various ways to structure a test, depending on what one wants
 to test. Here are a few ideas on how to do it.
 
 === Non-interactive "GUI"
 
 If you want to test some operations in the user interface, a useful
 approach is is to write a custom "GUI" simulating the operations.
 This can be done by creating a normal LinuxCNC setup and pointing the
-[DISPLAY] DISPLAY value to a script that do the operations needed to
+[DISPLAY] DISPLAY value to a script that does the operations needed to
 test the behaviour.
 
 Examples of this approach can be found in `tests/halui/jogging/` and
@@ -118,7 +118,7 @@ Examples of this approach can be found in `tests/halui/jogging/` and
 Using the _sampler_ and _halsampler_ HAL components, one can set up a
 HAL configuration and collect pin value settings and changes and dump
 the result to stdout (or a file).  The end result can then be compared
-with the expected output to verify if HAL behave as expected.
+with the expected output to verify if HAL behaves as expected.
 
 Examples of this approach can be found in `tests/multiclick/` and
 `tests/stepgen.2/`.