diff --git a/src/test/README.md b/src/test/README.md
index c1fdc17c8..9cb765107 100644
--- a/src/test/README.md
+++ b/src/test/README.md
@@ -5,18 +5,15 @@ sense to simply use this framework rather than require developers to
 configure some other framework (we want as few impediments to creating
 unit tests as possible).
 
-The build system is setup to compile an executable called "test_dash"
+The build system is setup to compile an executable called `test_dash`
 that runs all of the unit tests.  The main source file is called
-test_dash.cpp, which simply includes other files that contain the
-actual unit tests (outside of a couple required preprocessor
-directives).  The pattern is to create one test file for each class or
-source file for which you want to create unit tests.  The file naming
-convention is "<source_filename>_tests.cpp" and such files should wrap
-their tests in a test suite called "<source_filename>_tests".  For an
-examples of this pattern, examine uint160_tests.cpp and
-uint256_tests.cpp.
-
-Add the source files to /src/Makefile.test.include to add them to the build.
+test_dash.cpp. To add a new unit test file to our test suite you need 
+to add the file to `src/Makefile.test.include`. The pattern is to create 
+one test file for each class or source file for which you want to create 
+unit tests.  The file naming convention is `<source_filename>_tests.cpp` 
+and such files should wrap their tests in a test suite 
+called `<source_filename>_tests`. For an example of this pattern, 
+examine `uint256_tests.cpp`.
 
 For further reading, I found the following website to be helpful in
 explaining how the boost unit test framework works:
@@ -31,5 +28,5 @@ example, to run just the getarg_tests verbosely:
 
     test_dash --run_test=getarg_tests/doubledash
 
-Run  test_dash --help   for the full list.
+Run `test_dash --help` for the full list.