Copy edit README.md

Make minor copy edits.

UNITTESTS/README.md

@@ -5,40 +5,44 @@ This document describes how to run and write unit tests for Mbed OS. Please see
 ## Prerequisites
 
 * GNU toolchains installed.
-    * GCC 6 or later
-    	* MinGW-W64 is recommended, although any windows port of the above GCC versions should work
+    * GCC 6 or later.
+    	* We recommend you use MinGW-W64, but any Windows port of the above GCC versions works.
 * CMake 3.0+ installed.
 * Python 2.7.x or >3.5 and pip 10.0 (or newer) installed.
 * gcovr >=4.1
 
 ### Installing dependencies on Debian/Ubuntu
 
 1. `sudo apt-get -y install build-essential cmake`
-2. Install python and pip:
+2. Install Python and pip:
+
 ```
 sudo apt-get -y install python python-setuptools
 sudo easy_install pip
 ```
+
 3. Install [gcovr](#installing-covr).
 4. (Optional) Install [Mbed CLI](https://os.mbed.com/docs/latest/tools/arm-mbed-cli.html).
 
 ### Installing dependencies on Mac OS
 
 1. Install [Homebrew](https://brew.sh/).
-2. Install gcc compilers and cmake with: `brew install gcc cmake`
-3. Install python and pip:
+2. Install GCC compilers and cmake with: `brew install gcc cmake`.
+3. Install Python and pip:
+
 ```
 brew install python
 sudo easy_install pip
 ```
+
 3. Install [gcovr](#installing-covr).
 4. (Optional) Install [Mbed CLI](https://os.mbed.com/docs/latest/tools/arm-mbed-cli.html).
 
 ### Installing dependencies on Windows
 
 1. Download and install [MinGW-W64](http://mingw-w64.org/).
 2. Download CMake binaries from https://cmake.org/download/ and run the installer.
-3. Download Python2.7 or Python3 from https://www.python.org/getit/ and run the installer.
+3. Download Python 2.7 or Python 3 from https://www.python.org/getit/, and run the installer.
 4. Add MinGW, CMake and Python into PATH.
 5. Install [gcovr](#installing-covr).
 6. (Optional) Install [Mbed CLI](https://os.mbed.com/docs/latest/tools/arm-mbed-cli.html).
@@ -49,16 +53,19 @@ Install gcovr code coverage tool globally with `pip install 'gcovr>=4.1'` or usi
 
 #### virtualenv
 
-1. Install virtualenv if not installed with `pip install virtualenv`
+1. Install virtualenv if not installed with `pip install virtualenv`.
 2. Install gcovr with:
 
 **[Debian/Linux/Mac OS]**
+
 ```
 virtualenv pyenv
 . pyenv/bin/activate
 pip install 'gcovr>=4.1'
 ```
+
 **[Windows]**
+
 ```
 virtualenv pyenv
 pyenv\\Scripts\\activate
@@ -67,7 +74,7 @@ pip install "gcovr>=4.1"
 
 ## Building and running unit tests
 
-> In case of running into problems see [troubleshooting](#troubleshooting) section.
+> If you run into problems, see the [troubleshooting](#troubleshooting) section.
 
 `UNITTESTS/mbed_unittest.py` contains testing scripts for Mbed OS unit testing. Mbed CLI supports unit testing through `mbed test --unittests` command with the same arguments.
 
@@ -77,17 +84,17 @@ pip install "gcovr>=4.1"
 mbed test --unittests
 ```
 
-A subset of tests can be run by providing `-r` flag for the tool which runs tests matching a regular expression.
+A subset of tests can be run by providing `-r` flag for the tool, which runs tests matching a regular expression.
 
-e.g. `mbed test --unittests --run -r features_netsocket`
+For example, `mbed test --unittests --run -r features_netsocket`
 
 ### Build manually without Python tools
 
-1. Create a build directory e.g. `mkdir UNITTESTS/build`.
+1. Create a build directory. For example, `mkdir UNITTESTS/build`.
 2. Move to the build directory `cd UNITTESTS/build`.
-3. Run CMake with `cmake [RELATIVE PATH TO UNITTESTS DIR] [OPTIONAL ARGUMENTS]` e.g. `cmake ..`:
-	* Add `-g [generator]` argument if target other than Unix Makefiles e.g. MinGW `-g "MinGW Makefiles"`
-4. Run make program (make, gmake, mingw32-make, etc).
+3. Run CMake with `cmake [RELATIVE PATH TO UNITTESTS DIR] [OPTIONAL ARGUMENTS]`. For example, `cmake ..`:
+	* Add `-g [generator]` argument if target other than Unix Makefiles. For example, MinGW `-g "MinGW Makefiles"`.
+4. Run make program (make, gmake, mingw32-make and so on).
 
 ##### Run CMake and build Unix Makefiles (GNU make)
 
@@ -116,42 +123,48 @@ Keyword variables (usage `cmake -D<VARIABLE>(:<TYPE>)=<value>`:
 
 ### Run in terminal
 
-Unit tests can be run separately from each executable or by using ctest test runner. Run ctest with make program using target test. Options can be passed to ctest using ARGS argument. See [ctest manual](https://cmake.org/cmake/help/v3.0/manual/ctest.1.html) for more information.
+You can run unit tests separately from each executable or by using ctest test runner. Run ctest with make program using target test. Options can be passed to ctest using ARGS argument. See [ctest manual](https://cmake.org/cmake/help/v3.0/manual/ctest.1.html) for more information.
 
 Run ctest on test suite level:
+
 ```
 {MAKE_PROGRAM} test -C [RELATIVE PATH TO BUILD DIRECTORY]
 ```
-e.g. `make test -C UNITTESTS/build` or `mingw32-make test -C UNITTESTS/build`
+
+For example, `make test -C UNITTESTS/build` or `mingw32-make test -C UNITTESTS/build`
 
 Run ctest verbose (show each test case):
+
 ```
 {MAKE_PROGRAM} test -C UNITTESTS/build ARGS="-V"
 ```
 
 Run ctest dashboard test and create test results:
+
 ```
 {MAKE_PROGRAM} test --C UNITTESTS/build ARGS="-D ExperimentalTest"
 ```
 
 ### Run with GUI test runner
 
-1. Build and/or install *gtest-runner* using the documentation: https://github.com/nholthaus/gtest-runner
+1. Build and install *gtest-runner* using the documentation: https://github.com/nholthaus/gtest-runner.
 
 2. Run the application, add built test executables into the list and run it.
 
 ### Get code coverage
 
-Python tools use gcovr to build code coverage reports. Generate html report `UNITTESTS/build/coverage/index.html` with:
+Python tools use `gcovr` to build code coverage reports. Generate html report `UNITTESTS/build/coverage/index.html` with:
+
 ```
 mbed test --unittests --coverage html
 ```
 
-To get coverage for a single test suite, run gcovr separately for suite coverage data directory. See [gcovr documentation](https://gcovr.com/guide.html#filter-options) for more information.
+To get coverage for a single test suite, run `gcovr` separately for suite coverage data directory. See [gcovr documentation](https://gcovr.com/guide.html#filter-options) for more information.
 
-e.g. for features/netsocket/InternetSocket coverage:
+For example, for `features/netsocket/InternetSocket` coverage:
 
 Debian/Ubuntu/Mac OS:
+
 ```
 mkdir UNITTESTS/build
 cd UNITTESTS/build
@@ -160,7 +173,9 @@ make
 ./features_netsocket_InternetSocket
 gcovr -r ../.. --html --html-detail -o ./index.html ./CMakeFiles/features_netsocket_InternetSocket.MbedOS.dir/
 ```
+
 Windows:
+
 ```
 mkdir UNITTESTS/build
 cd UNITTESTS/build
@@ -173,6 +188,7 @@ gcovr -r ..\.. --html --html-detail -o .\index.html .\CMakeFiles\features_netsoc
 ## The structure of unit tests
 
 The structure of the unit tests directory looks like this:
+
 ```
 UNITTESTS
   ├── mbed_unittest.py                       Python tool for unit testing
@@ -193,17 +209,19 @@ UNITTESTS
   ├── target_h                               Shared headers which can be used for tests.
   └── template                               Templates for creating new unittests
 ```
-Each unit test has an identical directory tree as seen in the Mbed OS root folder. This is not a mandatory requirement but helps to maintain tests. Each class to be tested have their own `unittest.cmake` which is found by `CMakeLists.txt`.
+
+Each unit test has an identical directory tree as seen in the Mbed OS root folder. This is not a mandatory requirement but helps to maintain tests. Each class to be tested has its own `unittest.cmake`, which `CMakeLists.txt` finds.
 
 ## Creating a unit test
 
 Each class to be tested requires two files for unit testing:
-1. C++ unit test source file (e.g. `test_NetworkInterface.cpp`)
-2. CMake module file for unit test definition (`unittest.cmake`)
+
+1. C++ unit test source file (for example, `test_NetworkInterface.cpp`).
+2. CMake module file for unit test definition (`unittest.cmake`).
 
 A unit test definition file `unittest.cmake` requires variables to be set for a test to be configured. File source paths in `unittest.cmake` files need to be relative to the unit test folder and `CMakeLists.txt`.
 
-* **TEST_SUITE_NAME** - Identifier for the test suite. Use naming convention *PATH_TO_THE_TESTABLE_FILE* e.g. *features_netsocket_InternetSocket*
+* **TEST_SUITE_NAME** - Identifier for the test suite. Use naming convention *PATH_TO_THE_TESTABLE_FILE*. For example, *features_netsocket_InternetSocket*
 * **unittest-includes** - Include paths for headers needed to build the tests in addition to the base include paths listed in [CMakeLists.txt](CMakeLists.txt). Optional.
 * **unittest-sources** - Mbed OS source files and stubs included for the build.
 * **unittest-test-sources** - Unit test source files.
@@ -214,16 +232,17 @@ A unit test definition file `unittest.cmake` requires variables to be set for a
 mbed test --unittests --new <FILEPATH>
 ```
 
-E.g. `mbed test --unittests --new rtos/Semaphore.cpp`
+For example, `mbed test --unittests --new rtos/Semaphore.cpp`
 
-The generator script only creates the files required for a unit test. It does not write unit tests automatically nor does it handle source dependencies.
+The generator script only creates the files required for a unit test. It does not write unit tests automatically, nor does it handle source dependencies.
 
 #### Create files manually
 
-For example to create a unit test for `rtos/Semaphore.cpp`:
+For example, to create a unit test for `rtos/Semaphore.cpp`:
 
 1. Create a directory for unit test files in `UNITTESTS/rtos/Semaphore`.
 2. Create a test definition file `UNITTESTS/rtos/Semaphore/unittest.cmake` with the following content:
+
 ```
 set(TEST_SUITE_NAME "rtos_Semaphore")
 
@@ -236,7 +255,9 @@ set(unittest-test-sources
 	rtos/Semaphore/test_Semaphore.cpp
 )
 ```
+
 3. Create a test source file `UNITTESTS/rtos/Semaphore/test_Semaphore.cpp` with the following content:
+
 ```
 #include  "gtest/gtest.h"
 #include  "rtos/Semaphore.h"
@@ -289,6 +310,6 @@ TEST_F(TestSemaphore, constructor)
 
 ## Troubleshooting
 
-**Problem:** virus protection identifies files generated by CMake as malicious and quarantines the files on Windows.
+**Problem:** Virus protection identifies files generated by CMake as malicious and quarantines the files on Windows.
 
-* **Solution**: restore the false positive files from the quarantine.
+* **Solution**: Restore the false positive files from the quarantine.