ceedling 0.29.1 → 0.30.0

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

@@ -1,191 +1,191 @@
-# Unity - Getting Started
-
-## 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.
-
-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.
-
-
-#### 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.
-
-
-#### 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.
-
-
-#### 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.
-
-
-#### 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.
-
-
-### 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.
-
-
-## 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.
-
-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 a compiler
-that is configured to make these functions optional, you may leave them 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.
-
-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.  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 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:
-
-```C
-#include "unity.h"
-#include "file_to_test.h"
-
-void setUp(void) {
-    // set stuff up here
-}
-
-void tearDown(void) {
-    // clean stuff up here
-}
-
-void test_function_should_doBlahAndBlah(void) {
-    //test stuff
-}
-
-void test_function_should_doAlsoDoBlah(void) {
-    //more test stuff
-}
-
-int main(void) {
-    UNITY_BEGIN();
-    RUN_TEST(test_function_should_doBlahAndBlah);
-    RUN_TEST(test_function_should_doAlsoDoBlah);
-    return UNITY_END();
-}
-```
-
-It's possible that you will require more customization than this, eventually.
-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.
-
-
-## 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.
-
-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.
-
-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!
-
-
-*Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*
+# Unity - Getting Started
+
+## 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.
+
+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.
+
+
+#### 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.
+
+
+#### 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.
+
+
+#### 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.
+
+
+#### 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.
+
+
+### 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.
+
+
+## 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.
+
+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 a compiler
+that is configured to make these functions optional, you may leave them 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.
+
+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.  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 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:
+
+```C
+#include "unity.h"
+#include "file_to_test.h"
+
+void setUp(void) {
+    // set stuff up here
+}
+
+void tearDown(void) {
+    // clean stuff up here
+}
+
+void test_function_should_doBlahAndBlah(void) {
+    //test stuff
+}
+
+void test_function_should_doAlsoDoBlah(void) {
+    //more test stuff
+}
+
+int main(void) {
+    UNITY_BEGIN();
+    RUN_TEST(test_function_should_doBlahAndBlah);
+    RUN_TEST(test_function_should_doAlsoDoBlah);
+    return UNITY_END();
+}
+```
+
+It's possible that you will require more customization than this, eventually.
+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.
+
+
+## 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.
+
+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.
+
+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!
+
+
+*Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*

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

@@ -1,242 +1,242 @@
-# Unity Helper Scripts
-
-## 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 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/).
-
-
-### `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?
-
-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!
-
-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)
-{
-  ASSERT_TRUE(1);
-}
-void test_FunctionName_should_WorkProperlyAndReturn8(void) {
-  ASSERT_EQUAL_INT(8, FunctionName());
-}
-void spec_Function_should_DoWhatItIsSupposedToDo(void) {
-  ASSERT_NOT_NULL(Function(5));
-}
-```
-
-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.
-
-```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.
-
-```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.
-
-```YAML
-:unity:
-  :includes:
-    - stdio.h
-    - microdefs.h
-  :cexception: 1
-  :suit_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:
-
-```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:
-
-```Ruby
-require "generate_test_runner.rb"
-options = {
-  :includes => ["stdio.h", "microdefs.h"],
-  :cexception => 1,
-  :suite_setup => "blah = malloc(1024);",
-  :suite_teardown => "free(blah);"
-}
-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 thereafter. Like thus:
-
-```Ruby
-gen = UnityTestRunnerGenerator.new(options)
-test_files.each do |f|
-  gen.run(f, File.basename(f,'.c')+"Runner.c"
-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.
-
-
-##### `: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.
-
-
-##### `:suite_setup`
-
-Define this option with C code to be executed _before any_ test cases are run.
-
-
-##### `:suite_teardown`
-
-Define this option with C code to be executed ?after all?test cases have
-finished.
-
-
-##### `: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.
-
-
-##### `: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:
-
-```Ruby
-:plugins => [ :cexception ]
-```
-
-Or as a yaml file:
-
-```YAML
-:plugins:
-  -: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.
-
-
-### `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:
-
-```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.
-
-```Shell
-ruby unity_test_summary.rb build/test/ ~/projects/myproject/
-```
-
-Or, if you're more of a Windows sort of person:
-
-```Shell
-ruby unity_test_summary.rb build\teat\ C:\projects\myproject\
-```
-
-When configured correctly, you'll see a final summary, like so:
-
-```Shell
---------------------------
-UNITY IGNORED TEST SUMMARY
---------------------------
-blah.c:22:test_sandwiches_should_HaveBreadOnTwoSides:IGNORE
-
--------------------------
-UNITY FAILED TEST SUMMARY
--------------------------
-blah.c:87:test_sandwiches_should_HaveCondiments:FAIL:Expected 1 was 0
-meh.c:38:test_soda_should_BeCalledPop:FAIL:Expected "pop" was "coke"
-
---------------------------
-OVERALL UNITY TEST SUMMARY
---------------------------
-45 TOTAL TESTS 2 TOTAL FAILURES 1 IGNORED
-```
-
-How convenient is that?
-
-
-*Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*
+# Unity Helper Scripts
+
+## 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 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/).
+
+
+### `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?
+
+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!
+
+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)
+{
+  ASSERT_TRUE(1);
+}
+void test_FunctionName_should_WorkProperlyAndReturn8(void) {
+  ASSERT_EQUAL_INT(8, FunctionName());
+}
+void spec_Function_should_DoWhatItIsSupposedToDo(void) {
+  ASSERT_NOT_NULL(Function(5));
+}
+```
+
+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.
+
+```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.
+
+```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.
+
+```YAML
+:unity:
+  :includes:
+    - stdio.h
+    - microdefs.h
+  :cexception: 1
+  :suit_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:
+
+```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:
+
+```Ruby
+require "generate_test_runner.rb"
+options = {
+  :includes => ["stdio.h", "microdefs.h"],
+  :cexception => 1,
+  :suite_setup => "blah = malloc(1024);",
+  :suite_teardown => "free(blah);"
+}
+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 thereafter. Like thus:
+
+```Ruby
+gen = UnityTestRunnerGenerator.new(options)
+test_files.each do |f|
+  gen.run(f, File.basename(f,'.c')+"Runner.c"
+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.
+
+
+##### `: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.
+
+
+##### `:suite_setup`
+
+Define this option with C code to be executed _before any_ test cases are run.
+
+
+##### `:suite_teardown`
+
+Define this option with C code to be executed ?after all?test cases have
+finished.
+
+
+##### `: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.
+
+
+##### `: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:
+
+```Ruby
+:plugins => [ :cexception ]
+```
+
+Or as a yaml file:
+
+```YAML
+:plugins:
+  -: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.
+
+
+### `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:
+
+```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.
+
+```Shell
+ruby unity_test_summary.rb build/test/ ~/projects/myproject/
+```
+
+Or, if you're more of a Windows sort of person:
+
+```Shell
+ruby unity_test_summary.rb build\teat\ C:\projects\myproject\
+```
+
+When configured correctly, you'll see a final summary, like so:
+
+```Shell
+--------------------------
+UNITY IGNORED TEST SUMMARY
+--------------------------
+blah.c:22:test_sandwiches_should_HaveBreadOnTwoSides:IGNORE
+
+-------------------------
+UNITY FAILED TEST SUMMARY
+-------------------------
+blah.c:87:test_sandwiches_should_HaveCondiments:FAIL:Expected 1 was 0
+meh.c:38:test_soda_should_BeCalledPop:FAIL:Expected "pop" was "coke"
+
+--------------------------
+OVERALL UNITY TEST SUMMARY
+--------------------------
+45 TOTAL TESTS 2 TOTAL FAILURES 1 IGNORED
+```
+
+How convenient is that?
+
+
+*Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*