ceedling 0.31.0 → 0.31.1

data/vendor/cmock/vendor/unity/docs/UnityGettingStartedGuide.md

@@ -2,123 +2,104 @@
 
 ## Welcome
 
-Congratulations. You're now the proud owner of your very own pile of bits! What
-are you going to do with all these ones and zeros? This document should be able
-to help you decide just that.
+Congratulations.
+You're now the proud owner of your very own pile of bits!
+What are you going to do with all these ones and zeros?
+This document should be able to help you decide just that.
 
-Unity is a unit test framework. The goal has been to keep it small and
-functional. The core Unity test framework is three files: a single C file and a
-couple header files. These team up to provide functions and macros to make
-testing easier.
-
-Unity was designed to be cross-platform. It works hard to stick with C standards
-while still providing support for the many embedded C compilers that bend the
-rules. Unity has been used with many compilers, including GCC, IAR, Clang,
-Green Hills, Microchip, and MS Visual Studio. It's not much work to get it to
-work with a new target.
+Unity is a unit test framework.
+The goal has been to keep it small and functional.
+The core Unity test framework is three files: a single C file and a couple header files.
+These team up to provide functions and macros to make testing easier.
 
+Unity was designed to be cross-platform.
+It works hard to stick with C standards while still providing support for the many embedded C compilers that bend the rules.
+Unity has been used with many compilers, including GCC, IAR, Clang, Green Hills, Microchip, and MS Visual Studio.
+It's not much work to get it to work with a new target.
 
 ### Overview of the Documents
 
 #### Unity Assertions reference
 
-This document will guide you through all the assertion options provided by
-Unity. This is going to be your unit testing bread and butter. You'll spend more
-time with assertions than any other part of Unity.
-
+This document will guide you through all the assertion options provided by Unity.
+This is going to be your unit testing bread and butter.
+You'll spend more time with assertions than any other part of Unity.
 
 #### Unity Assertions Cheat Sheet
 
-This document contains an abridged summary of the assertions described in the
-previous document. It's perfect for printing and referencing while you
-familiarize yourself with Unity's options.
-
+This document contains an abridged summary of the assertions described in the previous document.
+It's perfect for printing and referencing while you familiarize yourself with Unity's options.
 
 #### Unity Configuration Guide
 
-This document is the one to reference when you are going to use Unity with a new
-target or compiler. It'll guide you through the configuration options and will
-help you customize your testing experience to meet your needs.
-
+This document is the one to reference when you are going to use Unity with a new target or compiler.
+It'll guide you through the configuration options and will help you customize your testing experience to meet your needs.
 
 #### Unity Helper Scripts
 
-This document describes the helper scripts that are available for simplifying
-your testing workflow. It describes the collection of optional Ruby scripts
-included in the auto directory of your Unity installation. Neither Ruby nor
-these scripts are necessary for using Unity. They are provided as a convenience
-for those who wish to use them.
-
+This document describes the helper scripts that are available for simplifying your testing workflow.
+It describes the collection of optional Ruby scripts included in the auto directory of your Unity installation.
+Neither Ruby nor these scripts are necessary for using Unity.
+They are provided as a convenience for those who wish to use them.
 
 #### Unity License
 
-What's an open source project without a license file? This brief document
-describes the terms you're agreeing to when you use this software. Basically, we
-want it to be useful to you in whatever context you want to use it, but please
-don't blame us if you run into problems.
-
+What's an open source project without a license file?
+This brief document describes the terms you're agreeing to when you use this software.
+Basically, we want it to be useful to you in whatever context you want to use it, but please don't blame us if you run into problems.
 
 ### Overview of the Folders
 
-If you have obtained Unity through Github or something similar, you might be
-surprised by just how much stuff you suddenly have staring you in the face.
-Don't worry, Unity itself is very small. The rest of it is just there to make
-your life easier. You can ignore it or use it at your convenience. Here's an
-overview of everything in the project.
-
-- `src` - This is the code you care about! This folder contains a C file and two
-header files. These three files _are_ Unity.
-- `docs` - You're reading this document, so it's possible you have found your way
-into this folder already. This is where all the handy documentation can be
-found.
-- `examples` - This contains a few examples of using Unity.
-- `extras` - These are optional add ons to Unity that are not part of the core
-project. If you've reached us through James Grenning's book, you're going to
-want to look here.
-- `test` - This is how Unity and its scripts are all tested. If you're just using
-Unity, you'll likely never need to go in here. If you are the lucky team member
-who gets to port Unity to a new toolchain, this is a good place to verify
-everything is configured properly.
-- `auto` - Here you will find helpful Ruby scripts for simplifying your test
-workflow. They are purely optional and are not required to make use of Unity.
+If you have obtained Unity through Github or something similar, you might be surprised by just how much stuff you suddenly have staring you in the face.
+Don't worry, Unity itself is very small.
+The rest of it is just there to make your life easier.
+You can ignore it or use it at your convenience.
+Here's an overview of everything in the project.
 
+- `src` - This is the code you care about! This folder contains a C file and two header files.
+  These three files _are_ Unity.
+- `docs` - You're reading this document, so it's possible you have found your way into this folder already.
+  This is where all the handy documentation can be found.
+- `examples` - This contains a few examples of using Unity.
+- `extras` - These are optional add ons to Unity that are not part of the core project.
+  If you've reached us through James Grenning's book, you're going to want to look here.
+- `test` - This is how Unity and its scripts are all tested.
+  If you're just using Unity, you'll likely never need to go in here.
+  If you are the lucky team member who gets to port Unity to a new toolchain, this is a good place to verify everything is configured properly.
+- `auto` - Here you will find helpful Ruby scripts for simplifying your test workflow.
+  They are purely optional and are not required to make use of Unity.
 
 ## How to Create A Test File
 
-Test files are C files. Most often you will create a single test file for each C
-module that you want to test. The test file should include unity.h and the
-header for your C module to be tested.
+Test files are C files.
+Most often you will create a single test file for each C module that you want to test.
+The test file should include unity.h and the header for your C module to be tested.
 
-Next, a test file will include a `setUp()` and `tearDown()` function. The setUp
-function can contain anything you would like to run before each test. The
-tearDown function can contain anything you would like to run after each test.
-Both functions accept no arguments and return nothing. You may leave either or
-both of these blank if you have no need for them.
+Next, a test file will include a `setUp()` and `tearDown()` function.
+The setUp function can contain anything you would like to run before each test.
+The tearDown function can contain anything you would like to run after each test.
+Both functions accept no arguments and return nothing.
+You may leave either or both of these blank if you have no need for them.
 
-If you're using Ceedling or the test runner generator script, you may leave these off
-completely. Not sure? Give it a try. If you compiler complains that it can't
-find setUp or tearDown when it links, you'll know you need to at least include
-an empty function for these.
+If you're using Ceedling or the test runner generator script, you may leave these off completely.
+Not sure?
+Give it a try.
+If your compiler complains that it can't find setUp or tearDown when it links, you'll know you need to at least include an empty function for these.
 
-The majority of the file will be a series of test functions. Test functions
-follow the convention of starting with the word "test_" or "spec_". You don't HAVE
-to name them this way, but it makes it clear what functions are tests for other
-developers.  Also, the automated scripts that come with Unity or Ceedling will default
-to looking for test functions to be prefixed this way. Test functions take no arguments
-and return nothing. All test accounting is handled internally in Unity.
+The majority of the file will be a series of test functions.
+Test functions follow the convention of starting with the word "test_" or "spec_".
+You don't HAVE to name them this way, but it makes it clear what functions are tests for other developers.
+Also, the automated scripts that come with Unity or Ceedling will default to looking for test functions to be prefixed this way.
+Test functions take no arguments and return nothing. All test accounting is handled internally in Unity.
 
 Finally, at the bottom of your test file, you will write a `main()` function.
-This function will call `UNITY_BEGIN()`, then `RUN_TEST` for each test, and
-finally `UNITY_END()`.This is what will actually trigger each of those test
-functions to run, so it is important that each function gets its own `RUN_TEST`
-call.
-
-Remembering to add each test to the main function can get to be tedious. If you
-enjoy using helper scripts in your build process, you might consider making use
-of our handy [generate_test_runner.rb](../auto/generate_test_runner.rb) script.
-This will create the main function and all the calls for you, assuming that you
-have followed the suggested naming conventions. In this case, there is no need
-for you to include the main function in your test file at all.
+This function will call `UNITY_BEGIN()`, then `RUN_TEST` for each test, and finally `UNITY_END()`.
+This is what will actually trigger each of those test functions to run, so it is important that each function gets its own `RUN_TEST` call.
+
+Remembering to add each test to the main function can get to be tedious.
+If you enjoy using helper scripts in your build process, you might consider making use of our handy [generate_test_runner.rb][] script.
+This will create the main function and all the calls for you, assuming that you have followed the suggested naming conventions.
+In this case, there is no need for you to include the main function in your test file at all.
 
 When you're done, your test file will look something like this:
 
@@ -156,24 +137,29 @@ For that sort of thing, you're going to want to look at the configuration guide.
 This should be enough to get you going, though.
 
 ### Running Test Functions
-When writing your own `main()` functions, for a test-runner. There are two ways
-to execute the test.
+
+When writing your own `main()` functions, for a test-runner.
+There are two ways to execute the test.
 
 The classic variant
+
 ``` c
 RUN_TEST(func, linenum)
 ```
-or its simpler replacement that starts at the beginning of the function.
+
+Or its simpler replacement that starts at the beginning of the function.
+
 ``` c
 RUN_TEST(func)
 ```
-These macros perform the necessary setup before the test is called and
-handles cleanup and result tabulation afterwards.
+
+These macros perform the necessary setup before the test is called and handles clean-up and result tabulation afterwards.
 
 ### Ignoring Test Functions
+
 There are times when a test is incomplete or not valid for some reason.
-At these times, TEST_IGNORE can be called. Control will immediately be
-returned to the caller of the test, and no failures will be returned.
+At these times, TEST_IGNORE can be called.
+Control will immediately be returned to the caller of the test, and no failures will be returned.
 This is useful when your test runners are automatically generated.
 
 ``` c
@@ -182,25 +168,35 @@ TEST_IGNORE()
 
 Ignore this test and return immediately
 
-``` c
+```c
 TEST_IGNORE_MESSAGE (message)
 ```
 
-Ignore this test and return immediately. Output a message stating why the test was ignored.
+Ignore this test and return immediately.
+Output a message stating why the test was ignored.
 
 ### Aborting Tests
-There are times when a test will contain an infinite loop on error conditions, or there may be reason to escape from the test early without executing the rest of the test.  A pair of macros support this functionality in Unity.  The first `TEST_PROTECT` sets up the feature, and handles emergency abort cases. `TEST_ABORT` can then be used at any time within the tests to return to the last `TEST_PROTECT` call.
 
+There are times when a test will contain an infinite loop on error conditions, or there may be reason to escape from the test early without executing the rest of the test.
+A pair of macros support this functionality in Unity.
+The first `TEST_PROTECT` sets up the feature, and handles emergency abort cases.
+`TEST_ABORT` can then be used at any time within the tests to return to the last `TEST_PROTECT` call.
+
+```c
     TEST_PROTECT()
+```
 
 Setup and Catch macro
 
+```c
     TEST_ABORT()
+```
 
 Abort Test macro
 
 Example:
 
+```c
     main()
     {
         if (TEST_PROTECT())
@@ -208,44 +204,39 @@ Example:
             MyTest();
         }
     }
+```
 
 If MyTest calls `TEST_ABORT`, program control will immediately return to `TEST_PROTECT` with a return value of zero.
 
-
-
 ## How to Build and Run A Test File
 
-This is the single biggest challenge to picking up a new unit testing framework,
-at least in a language like C or C++. These languages are REALLY good at getting
-you "close to the metal" (why is the phrase metal? Wouldn't it be more accurate
-to say "close to the silicon"?). While this feature is usually a good thing, it
-can make testing more challenging.
+This is the single biggest challenge to picking up a new unit testing framework, at least in a language like C or C++.
+These languages are REALLY good at getting you "close to the metal" (why is the phrase metal? Wouldn't it be more accurate to say "close to the silicon"?).
+While this feature is usually a good thing, it can make testing more challenging.
 
-You have two really good options for toolchains. Depending on where you're
-coming from, it might surprise you that neither of these options is running the
-unit tests on your hardware.
+You have two really good options for toolchains.
+Depending on where you're coming from, it might surprise you that neither of these options is running the unit tests on your hardware.
 There are many reasons for this, but here's a short version:
+
 - On hardware, you have too many constraints (processing power, memory, etc),
 - On hardware, you don't have complete control over all registers,
 - On hardware, unit testing is more challenging,
 - Unit testing isn't System testing. Keep them separate.
 
-Instead of running your tests on your actual hardware, most developers choose to
-develop them as native applications (using gcc or MSVC for example) or as
-applications running on a simulator. Either is a good option. Native apps have
-the advantages of being faster and easier to set up. Simulator apps have the
-advantage of working with the same compiler as your target application. The
-options for configuring these are discussed in the configuration guide.
+Instead of running your tests on your actual hardware, most developers choose to develop them as native applications (using gcc or MSVC for example) or as applications running on a simulator.
+Either is a good option.
+Native apps have the advantages of being faster and easier to set up.
+Simulator apps have the advantage of working with the same compiler as your target application.
+The options for configuring these are discussed in the configuration guide.
 
-To get either to work, you might need to make a few changes to the file
-containing your register set (discussed later).
+To get either to work, you might need to make a few changes to the file containing your register set (discussed later).
 
-In either case, a test is built by linking unity, the test file, and the C
-file(s) being tested. These files create an executable which can be run as the
-test set for that module. Then, this process is repeated for the next test file.
-This flexibility of separating tests into individual executables allows us to
-much more thoroughly unit test our system and it keeps all the test code out of
-our final release!
+In either case, a test is built by linking unity, the test file, and the C file(s) being tested.
+These files create an executable which can be run as the test set for that module.
+Then, this process is repeated for the next test file.
+This flexibility of separating tests into individual executables allows us to much more thoroughly unit test our system and it keeps all the test code out of our final release!
 
+*Find The Latest of This And More at [ThrowTheSwitch.org][]*
 
-*Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*
+[generate_test_runner.rb]: ../auto/generate_test_runner.rb
+[ThrowTheSwitch.org]: https://throwtheswitch.org

data/vendor/cmock/vendor/unity/docs/UnityHelperScriptsGuide.md

@@ -3,30 +3,25 @@
 ## With a Little Help From Our Friends
 
 Sometimes what it takes to be a really efficient C programmer is a little non-C.
-The Unity project includes a couple of Ruby scripts for making your life just a tad
-easier. They are completely optional. If you choose to use them, you'll need a
-copy of Ruby, of course. Just install whatever the latest version is, and it is
-likely to work. You can find Ruby at [ruby-lang.org](https://ruby-labg.org/).
-
+The Unity project includes a couple of Ruby scripts for making your life just a tad easier.
+They are completely optional.
+If you choose to use them, you'll need a copy of Ruby, of course.
+Just install whatever the latest version is, and it is likely to work. You can find Ruby at [ruby-lang.org][].
 
 ### `generate_test_runner.rb`
 
-Are you tired of creating your own `main` function in your test file? Do you
-keep forgetting to add a `RUN_TEST` call when you add a new test case to your
-suite? Do you want to use CMock or other fancy add-ons but don't want to figure
-out how to create your own `RUN_TEST` macro?
+Are you tired of creating your own `main` function in your test file?
+Do you keep forgetting to add a `RUN_TEST` call when you add a new test case to your suite?
+Do you want to use CMock or other fancy add-ons but don't want to figure out how to create your own `RUN_TEST` macro?
 
 Well then we have the perfect script for you!
 
-The `generate_test_runner` script processes a given test file and automatically
-creates a separate test runner file that includes ?main?to execute the test
-cases within the scanned test file. All you do then is add the generated runner
-to your list of files to be compiled and linked, and presto you're done!
+The `generate_test_runner` script processes a given test file and automatically creates a separate test runner file that includes ?main?to execute the test cases within the scanned test file.
+All you do then is add the generated runner to your list of files to be compiled and linked, and presto you're done!
 
-This script searches your test file for void function signatures having a
-function name beginning with "test" or "spec". It treats each of these
-functions as a test case and builds up a test suite of them. For example, the
-following includes three test cases:
+This script searches your test file for void function signatures having a function name beginning with "test" or "spec".
+It treats each of these functions as a test case and builds up a test suite of them.
+For example, the following includes three test cases:
 
 ```C
 void testVerifyThatUnityIsAwesomeAndWillMakeYourLifeEasier(void)
@@ -41,32 +36,30 @@ void spec_Function_should_DoWhatItIsSupposedToDo(void) {
 }
 ```
 
-You can run this script a couple of ways. The first is from the command line:
+You can run this script a couple of ways.
+The first is from the command line:
 
 ```Shell
 ruby generate_test_runner.rb TestFile.c NameOfRunner.c
 ```
 
-Alternatively, if you include only the test file parameter, the script will copy
-the name of the test file and automatically append `_Runner` to the name of the
-generated file. The example immediately below will create TestFile_Runner.c.
+Alternatively, if you include only the test file parameter, the script will copy the name of the test file and automatically append `_Runner` to the name of the generated file.
+The example immediately below will create TestFile_Runner.c.
 
 ```Shell
 ruby generate_test_runner.rb TestFile.c
 ```
 
-You can also add a [YAML](http://www.yaml.org/) file to configure extra options.
-Conveniently, this YAML file is of the same format as that used by Unity and
-CMock. So if you are using YAML files already, you can simply pass the very same
-file into the generator script.
+You can also add a [YAML][] file to configure extra options.
+Conveniently, this YAML file is of the same format as that used by Unity and CMock.
+So if you are using YAML files already, you can simply pass the very same file into the generator script.
 
 ```Shell
 ruby generate_test_runner.rb TestFile.c my_config.yml
 ```
 
-The contents of the YAML file `my_config.yml` could look something like the
-example below. If you're wondering what some of these options do, you're going
-to love the next section of this document.
+The contents of the YAML file `my_config.yml` could look something like the example below.
+If you're wondering what some of these options do, you're going to love the next section of this document.
 
 ```YAML
 :unity:
@@ -74,23 +67,20 @@ to love the next section of this document.
     - stdio.h
     - microdefs.h
   :cexception: 1
-  :suit_setup: "blah = malloc(1024);"
+  :suite_setup: "blah = malloc(1024);"
   :suite_teardown: "free(blah);"
 ```
 
-If you would like to force your generated test runner to include one or more
-header files, you can just include those at the command line too. Just make sure
-these are _after_ the YAML file, if you are using one:
+If you would like to force your generated test runner to include one or more header files, you can just include those at the command line too.
+Just make sure these are _after_ the YAML file, if you are using one:
 
 ```Shell
 ruby generate_test_runner.rb TestFile.c my_config.yml extras.h
 ```
 
-Another option, particularly if you are already using Ruby to orchestrate your
-builds - or more likely the Ruby-based build tool Rake - is requiring this
-script directly. Anything that you would have specified in a YAML file can be
-passed to the script as part of a hash. Let's push the exact same requirement
-set as we did above but this time through Ruby code directly:
+Another option, particularly if you are already using Ruby to orchestrate your builds - or more likely the Ruby-based build tool Rake - is requiring this script directly.
+Anything that you would have specified in a YAML file can be passed to the script as part of a hash.
+Let's push the exact same requirement set as we did above but this time through Ruby code directly:
 
 ```Ruby
 require "generate_test_runner.rb"
@@ -103,9 +93,8 @@ options = {
 UnityTestRunnerGenerator.new.run(testfile, runner_name, options)
 ```
 
-If you have multiple files to generate in a build script (such as a Rakefile),
-you might want to instantiate a generator object with your options and call it
-to generate each runner afterwards. Like thus:
+If you have multiple files to generate in a build script (such as a Rakefile), you might want to instantiate a generator object with your options and call it to generate each runner afterwards.
+Like thus:
 
 ```Ruby
 gen = UnityTestRunnerGenerator.new(options)
@@ -114,70 +103,54 @@ test_files.each do |f|
 end
 ```
 
-#### Options accepted by generate_test_runner.rb:
-
-The following options are available when executing `generate_test_runner`. You
-may pass these as a Ruby hash directly or specify them in a YAML file, both of
-which are described above. In the `examples` directory, Example 3's Rakefile
-demonstrates using a Ruby hash.
+#### Options accepted by generate_test_runner.rb
 
+The following options are available when executing `generate_test_runner`.
+You may pass these as a Ruby hash directly or specify them in a YAML file, both of which are described above.
+In the `examples` directory, Example 3's Rakefile demonstrates using a Ruby hash.
 
 ##### `:includes`
 
-This option specifies an array of file names to be `#include`'d at the top of
-your runner C file. You might use it to reference custom types or anything else
-universally needed in your generated runners.
-
+This option specifies an array of file names to be `#include`'d at the top of your runner C file.
+You might use it to reference custom types or anything else universally needed in your generated runners.
 
 ##### `:suite_setup`
 
 Define this option with C code to be executed _before any_ test cases are run.
 
-Alternatively, if your C compiler supports weak symbols, you can leave this
-option unset and instead provide a `void suiteSetUp(void)` function in your test
-suite.  The linker will look for this symbol and fall back to a Unity-provided
-stub if it is not found.
-
+Alternatively, if your C compiler supports weak symbols, you can leave this option unset and instead provide a `void suiteSetUp(void)` function in your test suite.
+The linker will look for this symbol and fall back to a Unity-provided stub if it is not found.
 
 ##### `:suite_teardown`
 
-Define this option with C code to be executed _after all_ test cases have
-finished.  An integer variable `num_failures` is available for diagnostics.
-The code should end with a `return` statement; the value returned will become
-the exit code of `main`.  You can normally just return `num_failures`.
-
-Alternatively, if your C compiler supports weak symbols, you can leave this
-option unset and instead provide a `int suiteTearDown(int num_failures)`
-function in your test suite.  The linker will look for this symbol and fall
-back to a Unity-provided stub if it is not found.
+Define this option with C code to be executed _after all_ test cases have finished.
+An integer variable `num_failures` is available for diagnostics.
+The code should end with a `return` statement; the value returned will become the exit code of `main`.
+You can normally just return `num_failures`.
 
+Alternatively, if your C compiler supports weak symbols, you can leave this option unset and instead provide a `int suiteTearDown(int num_failures)` function in your test suite.
+The linker will look for this symbol and fall back to a Unity-provided stub if it is not found.
 
 ##### `:enforce_strict_ordering`
 
-This option should be defined if you have the strict order feature enabled in
-CMock (see CMock documentation). This generates extra variables required for
-everything to run smoothly. If you provide the same YAML to the generator as
-used in CMock's configuration, you've already configured the generator properly.
-
+This option should be defined if you have the strict order feature enabled in CMock (see CMock documentation).
+This generates extra variables required for everything to run smoothly.
+If you provide the same YAML to the generator as used in CMock's configuration, you've already configured the generator properly.
 
 ##### `:externc`
 
-This option should be defined if you are mixing C and CPP and want your test
-runners to automatically include extern "C" support when they are generated.
+This option should be defined if you are mixing C and CPP and want your test runners to automatically include extern "C" support when they are generated.
 
 ##### `:mock_prefix` and `:mock_suffix`
 
-Unity automatically generates calls to Init, Verify and Destroy for every file
-included in the main test file that starts with the given mock prefix and ends
-with the given mock suffix, file extension not included. By default, Unity
-assumes a `Mock` prefix and no suffix.
+Unity automatically generates calls to Init, Verify and Destroy for every file included in the main test file that starts with the given mock prefix and ends with the given mock suffix, file extension not included.
+By default, Unity assumes a `Mock` prefix and no suffix.
 
 ##### `:plugins`
 
-This option specifies an array of plugins to be used (of course, the array can
-contain only a single plugin). This is your opportunity to enable support for
-CException support, which will add a check for unhandled exceptions in each
-test, reporting a failure if one is detected. To enable this feature using Ruby:
+This option specifies an array of plugins to be used (of course, the array can contain only a single plugin).
+This is your opportunity to enable support for CException support, which will add a check for unhandled exceptions in each test, reporting a failure if one is detected.
+To enable this feature using Ruby:
 
 ```Ruby
 :plugins => [ :cexception ]
@@ -190,57 +163,47 @@ Or as a yaml file:
   -:cexception
 ```
 
-If you are using CMock, it is very likely that you are already passing an array
-of plugins to CMock. You can just use the same array here. This script will just
-ignore the plugins that don't require additional support.
+If you are using CMock, it is very likely that you are already passing an array of plugins to CMock.
+You can just use the same array here.
+This script will just ignore the plugins that don't require additional support.
 
 ##### `:include_extensions`
 
 This option specifies the pattern for matching acceptable header file extensions.
-By default it will accept hpp, hh, H, and h files. If you need a different combination
-of files to search, update this from the default `'(?:hpp|hh|H|h)'`.
+By default it will accept hpp, hh, H, and h files.
+If you need a different combination of files to search, update this from the default `'(?:hpp|hh|H|h)'`.
 
 ##### `:source_extensions`
 
 This option specifies the pattern for matching acceptable source file extensions.
-By default it will accept cpp, cc, C, c, and ino files. If you need a different combination
-of files to search, update this from the default `'(?:cpp|cc|ino|C|c)'`.
-
+By default it will accept cpp, cc, C, c, and ino files.
+If you need a different combination of files to search, update this from the default `'(?:cpp|cc|ino|C|c)'`.
 
 ### `unity_test_summary.rb`
 
-A Unity test file contains one or more test case functions. Each test case can
-pass, fail, or be ignored. Each test file is run individually producing results
-for its collection of test cases. A given project will almost certainly be
-composed of multiple test files. Therefore, the suite of tests is comprised of
-one or more test cases spread across one or more test files. This script
-aggregates individual test file results to generate a summary of all executed
-test cases. The output includes how many tests were run, how many were ignored,
-and how many failed. In addition, the output includes a listing of which
-specific tests were ignored and failed. A good example of the breadth and
-details of these results can be found in the `examples` directory. Intentionally
-ignored and failing tests in this project generate corresponding entries in the
-summary report.
-
-If you're interested in other (prettier?) output formats, check into the
-Ceedling build tool project (ceedling.sourceforge.net) that works with Unity and
-CMock and supports xunit-style xml as well as other goodies.
-
-This script assumes the existence of files ending with the extensions
-`.testpass` and `.testfail`.The contents of these files includes the test
-results summary corresponding to each test file executed with the extension set
-according to the presence or absence of failures for that test file. The script
-searches a specified path for these files, opens each one it finds, parses the
-results, and aggregates and prints a summary. Calling it from the command line
-looks like this:
+A Unity test file contains one or more test case functions.
+Each test case can pass, fail, or be ignored.
+Each test file is run individually producing results for its collection of test cases.
+A given project will almost certainly be composed of multiple test files.
+Therefore, the suite of tests is comprised of one or more test cases spread across one or more test files.
+This script aggregates individual test file results to generate a summary of all executed test cases.
+The output includes how many tests were run, how many were ignored, and how many failed. In addition, the output includes a listing of which specific tests were ignored and failed.
+A good example of the breadth and details of these results can be found in the `examples` directory.
+Intentionally ignored and failing tests in this project generate corresponding entries in the summary report.
+
+If you're interested in other (prettier?) output formats, check into the [Ceedling][] build tool project that works with Unity and CMock and supports xunit-style xml as well as other goodies.
+
+This script assumes the existence of files ending with the extensions `.testpass` and `.testfail`.
+The contents of these files includes the test results summary corresponding to each test file executed with the extension set according to the presence or absence of failures for that test file.
+The script searches a specified path for these files, opens each one it finds, parses the results, and aggregates and prints a summary.
+Calling it from the command line looks like this:
 
 ```Shell
 ruby unity_test_summary.rb build/test/
 ```
 
-You can optionally specify a root path as well. This is really helpful when you
-are using relative paths in your tools' setup, but you want to pull the summary
-into an IDE like Eclipse for clickable shortcuts.
+You can optionally specify a root path as well.
+This is really helpful when you are using relative paths in your tools' setup, but you want to pull the summary into an IDE like Eclipse for clickable shortcuts.
 
 ```Shell
 ruby unity_test_summary.rb build/test/ ~/projects/myproject/
@@ -274,5 +237,9 @@ OVERALL UNITY TEST SUMMARY
 
 How convenient is that?
 
+*Find The Latest of This And More at [ThrowTheSwitch.org][]*
 
-*Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*
+[ruby-lang.org]: https://ruby-labg.org/
+[YAML]: http://www.yaml.org/
+[Ceedling]: http://www.throwtheswitch.org/ceedling
+[ThrowTheSwitch.org]: https://throwtheswitch.org