Merge pull request #815 from JamesB192/master

🐛🐧 Try build Unity w/ -DUNITY_EXCLUDE_FLOAT_PRINT

.github/FUNDING.yml

@@ -0,0 +1,13 @@
+github: ThrowTheSwitch
+#patreon: # Replace with a single Patreon username
+#open_collective: # Replace with a single Open Collective username
+#ko_fi: # Replace with a single Ko-fi username
+#tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel
+#community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry
+#liberapay: # Replace with a single Liberapay username
+#issuehunt: # Replace with a single IssueHunt username
+#lfx_crowdfunding: # Replace with a single LFX Crowdfunding project-name e.g., cloud-foundry
+#polar: # Replace with a single Polar username
+#buy_me_a_coffee: # Replace with a single Buy Me a Coffee username
+#thanks_dev: # Replace with a single thanks.dev username
+#custom: # Replace with up to 4 custom sponsorship URLs e.g., ['link1', 'link2']

.github/workflows/main.yml

@@ -0,0 +1,35 @@
+---
+# Continuous Integration Workflow: Test case suite run + validation build check
+name: CI
+
+# Controls when the action will run.
+# Triggers the workflow on push or pull request events but only for the master branch
+on:
+  push:
+    branches: [ master ]
+  pull_request:
+    branches: [ master ]
+
+jobs:
+  # Job: Unit test suite
+  unit-tests:
+    name: "Unit Tests"
+    runs-on: ubuntu-latest
+    strategy:
+      matrix:
+        ruby: ['2.7', '3.0', '3.1', '3.2']
+    steps:
+      # Install Ruby Testing Tools
+      - name: Setup Ruby Testing Tools
+        run: |
+          sudo gem install rspec
+          sudo gem install rubocop -v 1.57.2
+
+      # Checks out repository under $GITHUB_WORKSPACE
+      - name: Checkout Latest Repo
+        uses: actions/checkout@v4
+
+      # Run Tests
+      - name: Run All Unit Tests
+        run: |
+          cd test && rake ci

.gitignore

@@ -2,6 +2,7 @@ build/
 builddir/
 test/sandbox
 .DS_Store
+examples/example_1/subprojects/unity
 examples/example_1/test1.exe
 examples/example_1/test2.exe
 examples/example_2/all_tests.exe
@@ -9,3 +10,10 @@ examples/example_1/test1.out
 examples/example_1/test2.out
 examples/example_2/all_tests.out
 examples/example_4/builddir
+*.sublime-project
+*.sublime-workspace
+*.cmake
+Makefile
+CMakeFiles
+CMakeCache.txt
+!unityConfig.cmake

.travis.yml

@@ -1,26 +0,0 @@
-sudo: required
-language: ruby c
-
-matrix:
- include:
-    #- os: osx
-    #  compiler: clang
-    #  osx_image: xcode7.3
-    - os: linux
-      dist: trusty
-      rvm: "2.4"
-      compiler: gcc
-    - os: linux
-      dist: xenial
-      rvm: "2.7"
-      compiler: clang
-
-before_install:
-  - if [ "$TRAVIS_OS_NAME" == "linux" ]; then sudo apt-get install --assume-yes --quiet gcc-multilib; fi
-
-install:
-  - gem install rspec
-  - gem install rubocop -v 0.57.2
-
-script:
-  - cd test && rake ci

CMakeLists.txt

@@ -41,6 +41,21 @@ project(unity
     DESCRIPTION "C Unit testing framework."
 )
 
+# Options to Build With Extras -------------------------------------------------
+option(UNITY_EXTENSION_FIXTURE "Compiles Unity with the \"fixture\" extension." OFF)
+option(UNITY_EXTENSION_MEMORY "Compiles Unity with the \"memory\" extension." OFF)
+
+set(UNITY_EXTENSION_FIXTURE_ENABLED $<BOOL:${UNITY_EXTENSION_FIXTURE}>)
+set(UNITY_EXTENSION_MEMORY_ENABLED $<OR:${UNITY_EXTENSION_FIXTURE_ENABLED},$<BOOL:${UNITY_EXTENSION_MEMORY}>>)
+
+if(${UNITY_EXTENSION_FIXTURE})
+    message(STATUS "Unity: Building with the fixture extension.")
+endif()
+
+if(${UNITY_EXTENSION_MEMORY})
+    message(STATUS "Unity: Building with the memory extension.")
+endif()
+
 # Main target ------------------------------------------------------------------
 add_library(${PROJECT_NAME} STATIC)
 add_library(${PROJECT_NAME}::framework ALIAS ${PROJECT_NAME})
@@ -52,6 +67,8 @@ include(CMakePackageConfigHelpers)
 target_sources(${PROJECT_NAME}
     PRIVATE
         src/unity.c
+        $<$<BOOL:${UNITY_EXTENSION_FIXTURE_ENABLED}>:extras/fixture/src/unity_fixture.c>
+        $<$<BOOL:${UNITY_EXTENSION_MEMORY_ENABLED}>:extras/memory/src/unity_memory.c>
 )
 
 target_include_directories(${PROJECT_NAME}
@@ -59,10 +76,17 @@ target_include_directories(${PROJECT_NAME}
         $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/src>
         $<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}>
         $<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}/${PROJECT_NAME}>
+        $<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}>
+        $<BUILD_INTERFACE:$<$<BOOL:${UNITY_EXTENSION_MEMORY_ENABLED}>:${CMAKE_CURRENT_SOURCE_DIR}/extras/memory/src>>
+        $<BUILD_INTERFACE:$<$<BOOL:${UNITY_EXTENSION_FIXTURE_ENABLED}>:${CMAKE_CURRENT_SOURCE_DIR}/extras/fixture/src>>
 )
 
-set(${PROJECT_NAME}_PUBLIC_HEADERS src/unity.h
-                                   src/unity_internals.h
+set(${PROJECT_NAME}_PUBLIC_HEADERS
+        src/unity.h
+        src/unity_internals.h
+        $<$<BOOL:${UNITY_EXTENSION_FIXTURE_ENABLED}>:${CMAKE_CURRENT_SOURCE_DIR}/extras/fixture/src/unity_fixture.h>
+        $<$<BOOL:${UNITY_EXTENSION_FIXTURE_ENABLED}>:${CMAKE_CURRENT_SOURCE_DIR}/extras/fixture/src/unity_fixture_internals.h>
+        $<$<BOOL:${UNITY_EXTENSION_MEMORY_ENABLED}>:${CMAKE_CURRENT_SOURCE_DIR}/extras/memory/src/unity_memory.h>
 )
 
 set_target_properties(${PROJECT_NAME}
@@ -76,34 +100,49 @@ set_target_properties(${PROJECT_NAME}
 
 target_compile_options(${PROJECT_NAME}
     PRIVATE
-        $<$<C_COMPILER_ID:Clang>:-Wcast-align
-                                 -Wcast-qual
-                                 -Wconversion
-                                 -Wexit-time-destructors
-                                 -Wglobal-constructors
-                                 -Wmissing-noreturn
-                                 -Wmissing-prototypes
-                                 -Wno-missing-braces
-                                 -Wold-style-cast
-                                 -Wshadow
-                                 -Wweak-vtables>
-        $<$<C_COMPILER_ID:GNU>:-Waddress
-                               -Waggregate-return
-                               -Wformat-nonliteral
-                               -Wformat-security
-                               -Wformat
-                               -Winit-self
-                               -Wmissing-declarations
-                               -Wmissing-include-dirs
-                               -Wno-multichar
-                               -Wno-parentheses
-                               -Wno-type-limits
-                               -Wno-unused-parameter
-                               -Wunreachable-code
-                               -Wwrite-strings
-                               -Wpointer-arith>
-        -Wall
-        -Werror
+        # Clang
+        $<$<C_COMPILER_ID:Clang>:
+            -Wcast-align
+            -Wcast-qual
+            -Wconversion
+            -Wexit-time-destructors                            
+            -Wglobal-constructors
+            -Wmissing-noreturn
+            -Wmissing-prototypes
+            -Wno-missing-braces
+            -Wold-style-cast
+            -Wshadow
+            -Wweak-vtables
+            -Werror
+            -Wall
+            $<$<VERSION_GREATER_EQUAL:$<C_COMPILER_VERSION>,8.0.0>:-Wextra-semi-stmt>
+        >
+        
+        # GCC
+        $<$<C_COMPILER_ID:GNU>:
+            -Waddress
+            -Waggregate-return
+            -Wformat-nonliteral
+            -Wformat-security
+            -Wformat
+            -Winit-self
+            -Wmissing-declarations
+            -Wmissing-include-dirs
+            -Wno-multichar
+            -Wno-parentheses
+            -Wno-type-limits
+            -Wno-unused-parameter
+            -Wunreachable-code
+            -Wwrite-strings
+            -Wpointer-arith
+            -Werror
+            -Wall
+        >
+
+        # MSVC
+        $<$<C_COMPILER_ID:MSVC>:
+            /Wall
+        >
 )
 
 write_basic_package_version_file(${PROJECT_NAME}ConfigVersion.cmake

LICENSE.txt

@@ -1,6 +1,6 @@
 The MIT License (MIT)
 
-Copyright (c) <year> 2007-14 Mike Karlesky, Mark VanderVoord, Greg Williams
+Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

README.md

@@ -1,20 +1,28 @@
-Unity Test API
-==============
+# Unity Test ![CI][]
 
-[![Unity Build Status](https://api.travis-ci.org/ThrowTheSwitch/Unity.png?branch=master)](https://travis-ci.org/ThrowTheSwitch/Unity)
-__Copyright (c) 2007 - 2020 Unity Project by Mike Karlesky, Mark VanderVoord, and Greg Williams__
+__Copyright (c) 2007 - 2024 Unity Project by Mike Karlesky, Mark VanderVoord, and Greg Williams__
 
-Getting Started
-===============
-The [docs](docs/) folder contains a [getting started guide](docs/UnityGettingStartedGuide.md)
-and much more tips about using Unity. 
+Welcome to the Unity Test Project, one of the main projects of ThrowTheSwitch.org.
+Unity Test is a unit testing framework built for C, with a focus on working with embedded toolchains.
 
-Unity Assertion Summary
-=======================
-For the full list, see [UnityAssertionsReference.md](docs/UnityAssertionsReference.md).
+This project is made to test code targetting microcontrollers big and small.
+The core project is a single C file and a pair of headers, allowing it to be added to your existing build setup without too much headache.
+You may use any compiler you wish, and may use most existing build systems including Make, CMake, etc.
+If you'd like to leave the hard work to us, you might be interested in Ceedling, a build tool also by ThrowTheSwitch.org.
 
-Basic Validity Tests
---------------------
+If you're new to Unity, we encourage you to tour the [getting started guide][].
+
+You can also find the [change log][] and [known issues][] in our documentation.
+
+## Getting Started
+
+The [docs][] folder contains a [getting started guide][] and much more tips about using Unity.
+
+## Unity Assertion Summary
+
+For the full list, see [UnityAssertionsReference.md][].
+
+### Basic Validity Tests
 
     TEST_ASSERT_TRUE(condition)
 
@@ -35,10 +43,10 @@ Another way of calling `TEST_ASSERT_FALSE`
     TEST_FAIL()
     TEST_FAIL_MESSAGE(message)
 
-This test is automatically marked as a failure. The message is output stating why.
+This test is automatically marked as a failure.
+The message is output stating why.
 
-Numerical Assertions: Integers
-------------------------------
+### Numerical Assertions: Integers
 
     TEST_ASSERT_EQUAL_INT(expected, actual)
     TEST_ASSERT_EQUAL_INT8(expected, actual)
@@ -46,9 +54,9 @@ Numerical Assertions: Integers
     TEST_ASSERT_EQUAL_INT32(expected, actual)
     TEST_ASSERT_EQUAL_INT64(expected, actual)
 
-Compare two integers for equality and display errors as signed integers. A cast will be performed
-to your natural integer size so often this can just be used. When you need to specify the exact size,
-like when comparing arrays, you can use a specific version:
+Compare two integers for equality and display errors as signed integers.
+A cast will be performed to your natural integer size so often this can just be used.
+When you need to specify the exact size, you can use a specific version.
 
     TEST_ASSERT_EQUAL_UINT(expected, actual)
     TEST_ASSERT_EQUAL_UINT8(expected, actual)
@@ -56,8 +64,8 @@ like when comparing arrays, you can use a specific version:
     TEST_ASSERT_EQUAL_UINT32(expected, actual)
     TEST_ASSERT_EQUAL_UINT64(expected, actual)
 
-Compare two integers for equality and display errors as unsigned integers. Like INT, there are
-variants for different sizes also.
+Compare two integers for equality and display errors as unsigned integers.
+Like INT, there are variants for different sizes also.
 
     TEST_ASSERT_EQUAL_HEX(expected, actual)
     TEST_ASSERT_EQUAL_HEX8(expected, actual)
@@ -65,9 +73,9 @@ variants for different sizes also.
     TEST_ASSERT_EQUAL_HEX32(expected, actual)
     TEST_ASSERT_EQUAL_HEX64(expected, actual)
 
-Compares two integers for equality and display errors as hexadecimal. Like the other integer comparisons,
-you can specify the size... here the size will also effect how many nibbles are shown (for example, `HEX16`
-will show 4 nibbles).
+Compares two integers for equality and display errors as hexadecimal.
+Like the other integer comparisons, you can specify the size... 
+here the size will also affect how many nibbles are shown (for example, `HEX16` will show 4 nibbles).
 
     TEST_ASSERT_EQUAL(expected, actual)
 
@@ -75,96 +83,126 @@ Another way of calling TEST_ASSERT_EQUAL_INT
 
     TEST_ASSERT_INT_WITHIN(delta, expected, actual)
 
-Asserts that the actual value is within plus or minus delta of the expected value. This also comes in
-size specific variants.
-
+Asserts that the actual value is within plus or minus delta of the expected value.
+This also comes in size specific variants.
 
     TEST_ASSERT_GREATER_THAN(threshold, actual)
 
-Asserts that the actual value is greater than the threshold. This also comes in size specific variants.
-
+Asserts that the actual value is greater than the threshold.
+This also comes in size specific variants.
 
     TEST_ASSERT_LESS_THAN(threshold, actual)
 
-Asserts that the actual value is less than the threshold. This also comes in size specific variants.
+Asserts that the actual value is less than the threshold.
+This also comes in size specific variants.
 
-
-Arrays
-------
+### Arrays
 
     _ARRAY
 
-You can append `_ARRAY` to any of these macros to make an array comparison of that type.  Here you will
-need to care a bit more about the actual size of the value being checked.  You will also specify an
-additional argument which is the number of elements to compare.  For example:
+You can append `_ARRAY` to any of these macros to make an array comparison of that type.
+Here you will need to care a bit more about the actual size of the value being checked.
+You will also specify an additional argument which is the number of elements to compare.
+For example:
 
     TEST_ASSERT_EQUAL_HEX8_ARRAY(expected, actual, elements)
 
     _EACH_EQUAL
 
-Another array comparison option is to check that EVERY element of an array is equal to a single expected
-value. You do this by specifying the EACH_EQUAL macro. For example:
+Another array comparison option is to check that EVERY element of an array is equal to a single expected value.
+You do this by specifying the EACH_EQUAL macro.
+For example:
 
     TEST_ASSERT_EACH_EQUAL_INT32(expected, actual, elements)
 
-Numerical Assertions: Bitwise
------------------------------
+### Numerical Assertions: Bitwise
 
     TEST_ASSERT_BITS(mask, expected, actual)
 
-Use an integer mask to specify which bits should be compared between two other integers.  High bits in the mask are compared, low bits ignored.
+Use an integer mask to specify which bits should be compared between two other integers.
+High bits in the mask are compared, low bits ignored.
 
     TEST_ASSERT_BITS_HIGH(mask, actual)
 
-Use an integer mask to specify which bits should be inspected to determine if they are all set high.  High bits in the mask are compared, low bits ignored.
+Use an integer mask to specify which bits should be inspected to determine if they are all set high.
+High bits in the mask are compared, low bits ignored.
 
     TEST_ASSERT_BITS_LOW(mask, actual)
 
-Use an integer mask to specify which bits should be inspected to determine if they are all set low.  High bits in the mask are compared, low bits ignored.
+Use an integer mask to specify which bits should be inspected to determine if they are all set low.
+High bits in the mask are compared, low bits ignored.
 
     TEST_ASSERT_BIT_HIGH(bit, actual)
 
-Test a single bit and verify that it is high.  The bit is specified 0-31 for a 32-bit integer.
+Test a single bit and verify that it is high.
+The bit is specified 0-31 for a 32-bit integer.
 
     TEST_ASSERT_BIT_LOW(bit, actual)
 
-Test a single bit and verify that it is low.  The bit is specified 0-31 for a 32-bit integer.
+Test a single bit and verify that it is low.
+The bit is specified 0-31 for a 32-bit integer.
 
-Numerical Assertions: Floats
-----------------------------
+### Numerical Assertions: Floats
 
     TEST_ASSERT_FLOAT_WITHIN(delta, expected, actual)
+    TEST_ASSERT_DOUBLE_WITHIN(delta, expected, actual)
 
 Asserts that the actual value is within plus or minus delta of the expected value.
 
+    TEST_ASSERT_FLOAT_NOT_WITHIN(delta, expected, actual)
+    TEST_ASSERT_DOUBLE_NOT_WITHIN(delta, expected, actual)
+
+Asserts that the actual value is NOT within plus or minus delta of the expected value.
+
     TEST_ASSERT_EQUAL_FLOAT(expected, actual)
     TEST_ASSERT_EQUAL_DOUBLE(expected, actual)
 
 Asserts that two floating point values are "equal" within a small % delta of the expected value.
 
-String Assertions
------------------
+    TEST_ASSERT_NOT_EQUAL_FLOAT(expected, actual)
+    TEST_ASSERT_NOT_EQUAL_DOUBLE(expected, actual)
+
+Asserts that two floating point values are NOT "equal" within a small % delta of the expected value.
+
+    TEST_ASSERT_LESS_THAN_FLOAT(threshold, actual)
+    TEST_ASSERT_LESS_THAN_DOUBLE(threshold, actual)
+    TEST_ASSERT_GREATER_THAN_FLOAT(threshold, actual)
+    TEST_ASSERT_GREATER_THAN_DOUBLE(threshold, actual)
+
+Asserts that the actual value is less than or greater than the threshold.
+
+There are also `LESS_OR_EQUAL` and `GREATER_OR_EQUAL` variations.
+These obey the same rules for equality as do `TEST_ASSERT_EQUAL_FLOAT` and `TEST_ASSERT_EQUAL_DOUBLE`:
+If the two values are within a small % delta of the expected value, the assertion will pass.
+
+### String Assertions
 
     TEST_ASSERT_EQUAL_STRING(expected, actual)
 
-Compare two null-terminate strings.  Fail if any character is different or if the lengths are different.
+Compare two null-terminate strings.
+Fail if any character is different or if the lengths are different.
 
     TEST_ASSERT_EQUAL_STRING_LEN(expected, actual, len)
 
-Compare two strings.  Fail if any character is different, stop comparing after len characters.
+Compare two strings.
+Fail if any character is different, stop comparing after len characters.
 
     TEST_ASSERT_EQUAL_STRING_MESSAGE(expected, actual, message)
 
-Compare two null-terminate strings.  Fail if any character is different or if the lengths are different. Output a custom message on failure.
+Compare two null-terminate strings.
+Fail if any character is different or if the lengths are different.
+Output a custom message on failure.
 
     TEST_ASSERT_EQUAL_STRING_LEN_MESSAGE(expected, actual, len, message)
 
-Compare two strings. Fail if any character is different, stop comparing after len characters. Output a custom message on failure.
+Compare two strings.
+Fail if any character is different, stop comparing after len characters.
+Output a custom message on failure.
 
-Pointer Assertions
-------------------
+### Pointer Assertions
 
-Most pointer operations can be performed by simply using the integer comparisons above. However, a couple of special cases are added for clarity.
+Most pointer operations can be performed by simply using the integer comparisons above.
+However, a couple of special cases are added for clarity.
 
     TEST_ASSERT_NULL(pointer)
 
@@ -174,18 +212,23 @@ Fails if the pointer is not equal to NULL
 
 Fails if the pointer is equal to NULL
 
-Memory Assertions
------------------
+### Memory Assertions
 
     TEST_ASSERT_EQUAL_MEMORY(expected, actual, len)
 
-Compare two blocks of memory.  This is a good generic assertion for types that can't be coerced into acting like
-standard types... but since it's a memory compare, you have to be careful that your data types are packed.
+Compare two blocks of memory.
+This is a good generic assertion for types that can't be coerced into acting like standard types... 
+but since it's a memory compare, you have to be careful that your data types are packed.
 
-\_MESSAGE
----------
+### \_MESSAGE
 
-you can append \_MESSAGE to any of the macros to make them take an additional argument.  This argument
-is a string that will be printed at the end of the failure strings.  This is useful for specifying more
-information about the problem.
+You can append `\_MESSAGE` to any of the macros to make them take an additional argument.
+This argument is a string that will be printed at the end of the failure strings.
+This is useful for specifying more information about the problem.
 
+[CI]: https://github.com/ThrowTheSwitch/Unity/workflows/CI/badge.svg
+[getting started guide]: docs/UnityGettingStartedGuide.md
+[change log]: docs/UnityChangeLog.md
+[known issues]: docs/UnityKnownIssues.md
+[docs]: docs/
+[UnityAssertionsReference.md]: docs/UnityAssertionsReference.md

auto/__init__.py

@@ -0,0 +1,7 @@
+# =========================================================================
+#   Unity - A Test Framework for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
+

auto/colour_prompt.rb

@@ -1,8 +1,9 @@
-# ==========================================
-#   Unity Project - A Test Framework for C
-#   Copyright (c) 2007 Mike Karlesky, Mark VanderVoord, Greg Williams
-#   [Released under MIT License. Please refer to license.txt for details]
-# ==========================================
+# =========================================================================
+#   Unity - A Test Framework for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
 
 if RUBY_PLATFORM =~ /(win|w)32$/
   begin

auto/colour_reporter.rb

@@ -1,8 +1,9 @@
-# ==========================================
-#   Unity Project - A Test Framework for C
-#   Copyright (c) 2007 Mike Karlesky, Mark VanderVoord, Greg Williams
-#   [Released under MIT License. Please refer to license.txt for details]
-# ==========================================
+# =========================================================================
+#   Unity - A Test Framework for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
 
 require_relative 'colour_prompt'
 
@@ -12,7 +13,7 @@ def report(message)
   if !$colour_output
     $stdout.puts(message)
   else
-    message = message.join('\n') if message.class == Array
+    message = message.join('\n') if message.instance_of?(Array)
     message.each_line do |line|
       line.chomp!
       colour = case line

auto/extract_version.py

@@ -0,0 +1,22 @@
+#!/usr/bin/env python3
+# =========================================================================
+#   Unity - A Test Framework for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
+
+import re
+import sys
+
+ver_re = re.compile(r"^#define\s+UNITY_VERSION_(?:MAJOR|MINOR|BUILD)\s+(\d+)$")
+version = []
+
+with open(sys.argv[1], "r") as f:
+    for line in f:
+        m = ver_re.match(line)
+        if m:
+            version.append(m.group(1))
+
+print(".".join(version))
+

auto/generate_config.yml

@@ -1,3 +1,10 @@
+# =========================================================================
+#   Unity - A Test Framework for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
+
 #this is a sample configuration file for generate_module
 #you would use it by calling generate_module with the -ygenerate_config.yml option
 #files like this are useful for customizing generate_module to your environment

auto/generate_module.rb

@@ -1,8 +1,9 @@
-# ==========================================
-#   Unity Project - A Test Framework for C
-#   Copyright (c) 2007 Mike Karlesky, Mark VanderVoord, Greg Williams
-#   [Released under MIT License. Please refer to license.txt for details]
-# ==========================================
+# =========================================================================
+#   Unity - A Test Framework for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
 
 # This script creates all the files with start code necessary for a new module.
 # A simple module only requires a source file, header file, and test file.
@@ -13,7 +14,9 @@ require 'fileutils'
 require 'pathname'
 
 # TEMPLATE_TST
-TEMPLATE_TST ||= '#include "unity.h"
+TEMPLATE_TST ||= '#ifdef %5$s
+
+#include "unity.h"
 
 %2$s#include "%1$s.h"
 
@@ -29,6 +32,8 @@ void test_%4$s_NeedToImplement(void)
 {
     TEST_IGNORE_MESSAGE("Need to Implement %1$s");
 }
+
+#endif // %5$s
 '.freeze
 
 # TEMPLATE_SRC
@@ -104,7 +109,8 @@ class UnityModuleGenerator
       update_svn: false,
       boilerplates: {},
       test_prefix: 'Test',
-      mock_prefix: 'Mock'
+      mock_prefix: 'Mock',
+      test_define: 'TEST'
     }
   end
 
@@ -112,8 +118,8 @@ class UnityModuleGenerator
   def self.grab_config(config_file)
     options = default_options
     unless config_file.nil? || config_file.empty?
-      require 'yaml'
-      yaml_guts = YAML.load_file(config_file)
+      require_relative 'yaml_helper'
+      yaml_guts = YamlHelper.load_file(config_file)
       options.merge!(yaml_guts[:unity] || yaml_guts[:cmock])
       raise "No :unity or :cmock section found in #{config_file}" unless options
     end
@@ -128,9 +134,9 @@ class UnityModuleGenerator
 
     # create triad definition
     prefix = @options[:test_prefix] || 'Test'
-    triad = [{ ext: '.c', path: @options[:path_src], prefix: '', template: TEMPLATE_SRC, inc: :src, boilerplate: @options[:boilerplates][:src] },
+    triad = [{ ext: '.c', path: @options[:path_src], prefix: '',     template: TEMPLATE_SRC, inc: :src, boilerplate: @options[:boilerplates][:src] },
              { ext: '.h', path: @options[:path_inc], prefix: '',     template: TEMPLATE_INC, inc: :inc, boilerplate: @options[:boilerplates][:inc] },
-             { ext: '.c', path: @options[:path_tst], prefix: prefix, template: TEMPLATE_TST, inc: :tst, boilerplate: @options[:boilerplates][:tst] }]
+             { ext: '.c', path: @options[:path_tst], prefix: prefix, template: TEMPLATE_TST, inc: :tst, boilerplate: @options[:boilerplates][:tst], test_define: @options[:test_define] }]
 
     # prepare the pattern for use
     pattern = (pattern || @options[:pattern] || 'src').downcase
@@ -150,10 +156,11 @@ class UnityModuleGenerator
           path: (Pathname.new("#{cfg[:path]}#{subfolder}") + filename).cleanpath,
           name: submodule_name,
           template: cfg[:template],
+          test_define: cfg[:test_define],
           boilerplate: cfg[:boilerplate],
           includes: case (cfg[:inc])
                     when :src then (@options[:includes][:src] || []) | (pattern_traits[:inc].map { |f| format(f, module_name) })
-                    when :inc then (@options[:includes][:inc] || [])
+                    when :inc then  @options[:includes][:inc] || []
                     when :tst then (@options[:includes][:tst] || []) | (pattern_traits[:inc].map { |f| format("#{@options[:mock_prefix]}#{f}", module_name) })
                     end
         }
@@ -164,22 +171,20 @@ class UnityModuleGenerator
   end
 
   ############################
-  def neutralize_filename(name, start_cap=true)
+  def neutralize_filename(name, start_cap: true)
     return name if name.empty?
-    name = name.split(/(?:\s+|_|(?=[A-Z][a-z]))|(?<=[a-z])(?=[A-Z])/).map{|v|v.capitalize}.join('_')
-    if start_cap
-      return name
-    else
-      return name[0].downcase + name[1..-1]
-    end
+
+    name = name.split(/(?:\s+|_|(?=[A-Z][a-z]))|(?<=[a-z])(?=[A-Z])/).map(&:capitalize).join('_')
+    name = name[0].downcase + name[1..] unless start_cap
+    name
   end
 
   ############################
   def create_filename(part1, part2 = '')
-    name = part2.empty? ? part1 : part1 + '_' + part2
+    name = part2.empty? ? part1 : "#{part1}_#{part2}"
     case (@options[:naming])
-    when 'bumpy' then neutralize_filename(name,false).gsub('_','')
-    when 'camel' then neutralize_filename(name).gsub('_','')
+    when 'bumpy' then neutralize_filename(name, start_cap: false).delete('_')
+    when 'camel' then neutralize_filename(name).delete('_')
     when 'snake' then neutralize_filename(name).downcase
     when 'caps'  then neutralize_filename(name).upcase
     else              name
@@ -210,8 +215,9 @@ class UnityModuleGenerator
         f.write("#{file[:boilerplate]}\n" % [file[:name]]) unless file[:boilerplate].nil?
         f.write(file[:template] % [file[:name],
                                    file[:includes].map { |ff| "#include \"#{ff}\"\n" }.join,
-                                   file[:name].upcase.gsub(/-/, '_'),
-                                   file[:name].gsub(/-/, '_')])
+                                   file[:name].upcase.tr('-', '_'),
+                                   file[:name].tr('-', '_'),
+                                   file[:test_define]])
       end
       if @options[:update_svn]
         `svn add \"#{file[:path]}\"`
@@ -259,12 +265,12 @@ if $0 == __FILE__
     case arg
     when /^-d/            then destroy = true
     when /^-u/            then options[:update_svn] = true
-    when /^-p\"?(\w+)\"?/ then options[:pattern] = Regexp.last_match(1)
-    when /^-s\"?(.+)\"?/  then options[:path_src] = Regexp.last_match(1)
-    when /^-i\"?(.+)\"?/  then options[:path_inc] = Regexp.last_match(1)
-    when /^-t\"?(.+)\"?/  then options[:path_tst] = Regexp.last_match(1)
-    when /^-n\"?(.+)\"?/  then options[:naming] = Regexp.last_match(1)
-    when /^-y\"?(.+)\"?/  then options = UnityModuleGenerator.grab_config(Regexp.last_match(1))
+    when /^-p"?(\w+)"?/ then options[:pattern] = Regexp.last_match(1)
+    when /^-s"?(.+)"?/  then options[:path_src] = Regexp.last_match(1)
+    when /^-i"?(.+)"?/  then options[:path_inc] = Regexp.last_match(1)
+    when /^-t"?(.+)"?/  then options[:path_tst] = Regexp.last_match(1)
+    when /^-n"?(.+)"?/  then options[:naming] = Regexp.last_match(1)
+    when /^-y"?(.+)"?/  then options = UnityModuleGenerator.grab_config(Regexp.last_match(1))
     when /^(\w+)/
       raise "ERROR: You can't have more than one Module name specified!" unless module_name.nil?
 

auto/generate_test_runner.rb

@@ -1,8 +1,10 @@
-# ==========================================
-#   Unity Project - A Test Framework for C
-#   Copyright (c) 2007 Mike Karlesky, Mark VanderVoord, Greg Williams
-#   [Released under MIT License. Please refer to license.txt for details]
-# ==========================================
+#!/usr/bin/env ruby
+# =========================================================================
+#   Unity - A Test Framework for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
 
 class UnityTestRunnerGenerator
   def initialize(options = nil)
@@ -43,16 +45,19 @@ class UnityTestRunnerGenerator
       cmdline_args: false,
       omit_begin_end: false,
       use_param_tests: false,
+      use_system_files: true,
       include_extensions: '(?:hpp|hh|H|h)',
-      source_extensions: '(?:cpp|cc|ino|C|c)'
+      source_extensions: '(?:cpp|cc|ino|C|c)',
+      shuffle_tests: false,
+      rng_seed: 0
     }
   end
 
   def self.grab_config(config_file)
     options = default_options
     unless config_file.nil? || config_file.empty?
-      require 'yaml'
-      yaml_guts = YAML.load_file(config_file)
+      require_relative 'yaml_helper'
+      yaml_guts = YamlHelper.load_file(config_file)
       options.merge!(yaml_guts[:unity] || yaml_guts[:cmock])
       raise "No :unity or :cmock section found in #{config_file}" unless options
     end
@@ -67,7 +72,7 @@ class UnityTestRunnerGenerator
     source = source.force_encoding('ISO-8859-1').encode('utf-8', replace: nil)
     tests = find_tests(source)
     headers = find_includes(source)
-    testfile_includes = (headers[:local] + headers[:system])
+    testfile_includes = @options[:use_system_files] ? (headers[:local] + headers[:system]) : (headers[:local])
     used_mocks = find_mocks(testfile_includes)
     testfile_includes = (testfile_includes - used_mocks)
     testfile_includes.delete_if { |inc| inc =~ /(unity|cmock)/ }
@@ -78,7 +83,7 @@ class UnityTestRunnerGenerator
 
     # determine which files were used to return them
     all_files_used = [input_file, output_file]
-    all_files_used += testfile_includes.map { |filename| filename + '.c' } unless testfile_includes.empty?
+    all_files_used += testfile_includes.map { |filename| "#{filename}.c" } unless testfile_includes.empty?
     all_files_used += @options[:includes] unless @options[:includes].empty?
     all_files_used += headers[:linkonly] unless headers[:linkonly].empty?
     all_files_used.uniq
@@ -87,6 +92,7 @@ class UnityTestRunnerGenerator
   def generate(input_file, output_file, tests, used_mocks, testfile_includes)
     File.open(output_file, 'w') do |output|
       create_header(output, used_mocks, testfile_includes)
+      create_run_test_params_struct(output)
       create_externs(output, tests, used_mocks)
       create_mock_management(output, used_mocks)
       create_setup(output)
@@ -96,6 +102,7 @@ class UnityTestRunnerGenerator
       create_reset(output)
       create_run_test(output) unless tests.empty?
       create_args_wrappers(output, tests)
+      create_shuffle_tests(output) if @options[:shuffle_tests]
       create_main(output, input_file, tests, used_mocks)
     end
 
@@ -130,7 +137,8 @@ class UnityTestRunnerGenerator
 
     lines.each_with_index do |line, _index|
       # find tests
-      next unless line =~ /^((?:\s*(?:TEST_CASE|TEST_RANGE)\s*\(.*?\)\s*)*)\s*void\s+((?:#{@options[:test_prefix]}).*)\s*\(\s*(.*)\s*\)/m
+      next unless line =~ /^((?:\s*(?:TEST_(?:CASE|RANGE|MATRIX))\s*\(.*?\)\s*)*)\s*void\s+((?:#{@options[:test_prefix]}).*)\s*\(\s*(.*)\s*\)/m
+      next unless line =~ /^((?:\s*(?:TEST_(?:CASE|RANGE|MATRIX))\s*\(.*?\)\s*)*)\s*void\s+((?:#{@options[:test_prefix]})\w*)\s*\(\s*(.*)\s*\)/m
 
       arguments = Regexp.last_match(1)
       name = Regexp.last_match(2)
@@ -140,19 +148,38 @@ class UnityTestRunnerGenerator
 
       if @options[:use_param_tests] && !arguments.empty?
         args = []
-        arguments.scan(/\s*TEST_CASE\s*\((.*)\)\s*$/) { |a| args << a[0] }
+        type_and_args = arguments.split(/TEST_(CASE|RANGE|MATRIX)/)
+        (1...type_and_args.length).step(2).each do |i|
+          case type_and_args[i]
+          when 'CASE'
+            args << type_and_args[i + 1].sub(/^\s*\(\s*(.*?)\s*\)\s*$/m, '\1')
 
-        arguments.scan(/\s*TEST_RANGE\s*\((.*)\)\s*$/).flatten.each do |range_str|
-          args += range_str.scan(/\[(-?\d+.?\d*), *(-?\d+.?\d*), *(-?\d+.?\d*)\]/).map do |arg_values_str|
-            arg_values_str.map do |arg_value_str|
-              arg_value_str.include?('.') ? arg_value_str.to_f : arg_value_str.to_i
+          when 'RANGE'
+            args += type_and_args[i + 1].scan(/(\[|<)\s*(-?\d+.?\d*)\s*,\s*(-?\d+.?\d*)\s*,\s*(-?\d+.?\d*)\s*(\]|>)/m).map do |arg_values_str|
+              exclude_end = arg_values_str[0] == '<' && arg_values_str[-1] == '>'
+              arg_values_str[1...-1].map do |arg_value_str|
+                arg_value_str.include?('.') ? arg_value_str.to_f : arg_value_str.to_i
+              end.push(exclude_end)
+            end.map do |arg_values|
+              Range.new(arg_values[0], arg_values[1], arg_values[3]).step(arg_values[2]).to_a
+            end.reduce(nil) do |result, arg_range_expanded|
+              result.nil? ? arg_range_expanded.map { |a| [a] } : result.product(arg_range_expanded)
+            end.map do |arg_combinations|
+              arg_combinations.flatten.join(', ')
+            end
+
+          when 'MATRIX'
+            single_arg_regex_string = /(?:(?:"(?:\\"|[^\\])*?")+|(?:'\\?.')+|(?:[^\s\]\["',]|\[[\d\S_-]+\])+)/.source
+            args_regex = /\[((?:\s*#{single_arg_regex_string}\s*,?)*(?:\s*#{single_arg_regex_string})?\s*)\]/m
+            arg_elements_regex = /\s*(#{single_arg_regex_string})\s*,\s*/m
+
+            args += type_and_args[i + 1].scan(args_regex).flatten.map do |arg_values_str|
+              "#{arg_values_str},".scan(arg_elements_regex)
+            end.reduce do |result, arg_range_expanded|
+              result.product(arg_range_expanded)
+            end.map do |arg_combinations|
+              arg_combinations.flatten.join(', ')
             end
-          end.map do |arg_values|
-            (arg_values[0]..arg_values[1]).step(arg_values[2]).to_a
-          end.reduce do |result, arg_range_expanded|
-            result.product(arg_range_expanded)
-          end.map do |arg_combinations|
-            arg_combinations.flatten.join(', ')
           end
         end
       end
@@ -166,7 +193,7 @@ class UnityTestRunnerGenerator
     source_lines = source.split("\n")
     source_index = 0
     tests_and_line_numbers.size.times do |i|
-      source_lines[source_index..-1].each_with_index do |line, index|
+      source_lines[source_index..].each_with_index do |line, index|
         next unless line =~ /\s+#{tests_and_line_numbers[i][:test]}(?:\s|\()/
 
         source_index += index
@@ -185,19 +212,18 @@ class UnityTestRunnerGenerator
     source.gsub!(/\/\/.*$/, '')                          # remove line comments (all that remain)
 
     # parse out includes
-    includes = {
-      local: source.scan(/^\s*#include\s+\"\s*(.+\.#{@options[:include_extensions]})\s*\"/).flatten,
+    {
+      local: source.scan(/^\s*#include\s+"\s*(.+\.#{@options[:include_extensions]})\s*"/).flatten,
       system: source.scan(/^\s*#include\s+<\s*(.+)\s*>/).flatten.map { |inc| "<#{inc}>" },
-      linkonly: source.scan(/^TEST_FILE\(\s*\"\s*(.+\.#{@options[:source_extensions]})\s*\"/).flatten
+      linkonly: source.scan(/^TEST_SOURCE_FILE\(\s*"\s*(.+\.#{@options[:source_extensions]})\s*"/).flatten
     }
-    includes
   end
 
   def find_mocks(includes)
     mock_headers = []
     includes.each do |include_path|
       include_file = File.basename(include_path)
-      mock_headers << include_path if include_file =~ /^#{@options[:mock_prefix]}.*#{@options[:mock_suffix]}$/i
+      mock_headers << include_path if include_file =~ /^#{@options[:mock_prefix]}.*#{@options[:mock_suffix]}\.h$/i
     end
     mock_headers
   end
@@ -206,16 +232,46 @@ class UnityTestRunnerGenerator
     @options[:has_setup] = source =~ /void\s+#{@options[:setup_name]}\s*\(/
     @options[:has_teardown] = source =~ /void\s+#{@options[:teardown_name]}\s*\(/
     @options[:has_suite_setup] ||= (source =~ /void\s+suiteSetUp\s*\(/)
-    @options[:has_suite_teardown] ||= (source =~ /void\s+suiteTearDown\s*\(/)
+    @options[:has_suite_teardown] ||= (source =~ /int\s+suiteTearDown\s*\(int\s+([a-zA-Z0-9_])+\s*\)/)
+  end
+
+  def count_tests(tests)
+    if @options[:use_param_tests]
+      idx = 0
+      tests.each do |test|
+        if (test[:args].nil? || test[:args].empty?)
+          idx += 1
+        else
+          test[:args].each do |args|
+            idx += 1
+          end
+        end
+      end
+      return idx
+    else
+      return tests.size
+    end
   end
 
   def create_header(output, mocks, testfile_includes = [])
     output.puts('/* AUTOGENERATED FILE. DO NOT EDIT. */')
     output.puts("\n/*=======Automagically Detected Files To Include=====*/")
+    output.puts('extern "C" {') if @options[:externcincludes]
+    if @options[:shuffle_tests]
+      output.puts('#include <stdlib.h>')
+      if @options[:rng_seed] == 0
+        output.puts('#include <time.h>')
+      end
+    end
     output.puts("#include \"#{@options[:framework]}.h\"")
     output.puts('#include "cmock.h"') unless mocks.empty?
+    output.puts('}') if @options[:externcincludes]
     if @options[:defines] && !@options[:defines].empty?
-      @options[:defines].each { |d| output.puts("#ifndef #{d}\n#define #{d}\n#endif /* #{d} */") }
+      output.puts('/* injected defines for unity settings, etc */')
+      @options[:defines].each do |d|
+        def_only = d.match(/(\w+).*/)[1]
+        output.puts("#ifndef #{def_only}\n#define #{d}\n#endif /* #{def_only} */")
+      end
     end
     if @options[:header_file] && !@options[:header_file].empty?
       output.puts("#include \"#{File.basename(@options[:header_file])}\"")
@@ -227,9 +283,11 @@ class UnityTestRunnerGenerator
         output.puts("#include #{inc.include?('<') ? inc : "\"#{inc}\""}")
       end
     end
+    output.puts('extern "C" {') if @options[:externcincludes]
     mocks.each do |mock|
       output.puts("#include \"#{mock}\"")
     end
+    output.puts('}') if @options[:externcincludes]
     output.puts('#include "CException.h"') if @options[:plugins].include?(:cexception)
 
     return unless @options[:enforce_strict_ordering]
@@ -240,6 +298,16 @@ class UnityTestRunnerGenerator
     output.puts('char* GlobalOrderError;')
   end
 
+  def create_run_test_params_struct(output)
+    output.puts("\n/*=======Structure Used By Test Runner=====*/")
+    output.puts('struct UnityRunTestParameters')
+    output.puts('{')
+    output.puts('  UnityTestFunction func;')
+    output.puts('  const char* name;')
+    output.puts('  UNITY_LINE_TYPE line_num;')
+    output.puts('};')
+  end
+
   def create_externs(output, tests, _mocks)
     output.puts("\n/*=======External Functions This Runner Calls=====*/")
     output.puts("extern void #{@options[:setup_name]}(void);")
@@ -341,8 +409,9 @@ class UnityTestRunnerGenerator
 
   def create_run_test(output)
     require 'erb'
-    template = ERB.new(File.read(File.join(__dir__, 'run_test.erb')), nil, '<>')
-    output.puts("\n" + template.result(binding))
+    file = File.read(File.join(__dir__, 'run_test.erb'))
+    template = ERB.new(file, trim_mode: '<>')
+    output.puts("\n#{template.result(binding)}")
   end
 
   def create_args_wrappers(output, tests)
@@ -361,6 +430,22 @@ class UnityTestRunnerGenerator
     end
   end
 
+  def create_shuffle_tests(output)
+    output.puts("\n/*=======Shuffle Test Order=====*/")
+    output.puts('static void shuffleTests(struct UnityRunTestParameters run_test_params_arr[], int num_of_tests)')
+    output.puts('{')
+
+    # Use Fisher-Yates shuffle algorithm
+    output.puts('  for (int i = num_of_tests - 1; i > 0; i--)')
+    output.puts('  {')
+    output.puts('    int j = rand() % (i + 1);')
+    output.puts('    struct UnityRunTestParameters temp = run_test_params_arr[i];')
+    output.puts('    run_test_params_arr[i] = run_test_params_arr[j];')
+    output.puts('    run_test_params_arr[j] = temp;')
+    output.puts('  }')
+    output.puts('}')
+  end
+
   def create_main(output, filename, tests, used_mocks)
     output.puts("\n/*=======MAIN=====*/")
     main_name = @options[:main_name].to_sym == :auto ? "main_#{filename.gsub('.c', '')}" : (@options[:main_name]).to_s
@@ -370,12 +455,13 @@ class UnityTestRunnerGenerator
       end
       output.puts("#{@options[:main_export_decl]} int #{main_name}(int argc, char** argv)")
       output.puts('{')
+      output.puts('#ifdef UNITY_USE_COMMAND_LINE_ARGS')
       output.puts('  int parse_status = UnityParseOptions(argc, argv);')
       output.puts('  if (parse_status != 0)')
       output.puts('  {')
       output.puts('    if (parse_status < 0)')
       output.puts('    {')
-      output.puts("      UnityPrint(\"#{filename.gsub('.c', '')}.\");")
+      output.puts("      UnityPrint(\"#{filename.gsub('.c', '').gsub(/\\/, '\\\\\\')}.\");")
       output.puts('      UNITY_PRINT_EOL();')
       tests.each do |test|
         if (!@options[:use_param_tests]) || test[:args].nil? || test[:args].empty?
@@ -392,6 +478,7 @@ class UnityTestRunnerGenerator
       output.puts('    }')
       output.puts('    return parse_status;')
       output.puts('  }')
+      output.puts('#endif')
     else
       main_return = @options[:omit_begin_end] ? 'void' : 'int'
       if main_name != 'main'
@@ -406,33 +493,61 @@ class UnityTestRunnerGenerator
     else
       output.puts("  UnityBegin(\"#{filename.gsub(/\\/, '\\\\\\')}\");")
     end
+    if @options[:shuffle_tests]
+      output.puts
+      if @options[:rng_seed] == 0
+        output.puts('  srand(time(NULL));')
+      else
+        output.puts("  srand(#{@options[:rng_seed]});")
+      end
+    end
+    output.puts
+    output.puts("  int number_of_tests = #{count_tests(tests)};")
+    output.puts('  struct UnityRunTestParameters run_test_params_arr[number_of_tests];')
+    output.puts
+    idx = 0
     tests.each do |test|
       if (!@options[:use_param_tests]) || test[:args].nil? || test[:args].empty?
-        output.puts("  run_test(#{test[:test]}, \"#{test[:test]}\", #{test[:line_number]});")
+        output.puts("  run_test_params_arr[#{idx}].func = #{test[:test]};")
+        output.puts("  run_test_params_arr[#{idx}].name = \"#{test[:test]}\";")
+        output.puts("  run_test_params_arr[#{idx}].line_num = #{test[:line_number]};")
+        idx += 1
       else
-        test[:args].each.with_index(1) do |args, idx|
-          wrapper = "runner_args#{idx}_#{test[:test]}"
+        test[:args].each.with_index(1) do |args, arg_idx|
+          wrapper = "runner_args#{arg_idx}_#{test[:test]}"
           testname = "#{test[:test]}(#{args})".dump
-          output.puts("  run_test(#{wrapper}, #{testname}, #{test[:line_number]});")
+          output.puts("  run_test_params_arr[#{idx}].func = #{wrapper};")
+          output.puts("  run_test_params_arr[#{idx}].name = #{testname};")
+          output.puts("  run_test_params_arr[#{idx}].line_num = #{test[:line_number]};")
+          idx += 1
         end
       end
     end
     output.puts
+    if @options[:shuffle_tests]
+      output.puts('  shuffleTests(run_test_params_arr, number_of_tests);')
+      output.puts
+    end
+    output.puts('  for (int i = 0; i < number_of_tests; i++)')
+    output.puts('  {')
+    output.puts('    run_test(run_test_params_arr[i].func, run_test_params_arr[i].name, run_test_params_arr[i].line_num);')
+    output.puts('  }')
+    output.puts
     output.puts('  CMock_Guts_MemFreeFinal();') unless used_mocks.empty?
     if @options[:has_suite_teardown]
       if @options[:omit_begin_end]
         output.puts('  (void) suite_teardown(0);')
       else
-        output.puts('  return suiteTearDown(UnityEnd());')
+        output.puts('  return suiteTearDown(UNITY_END());')
       end
     else
-      output.puts('  return UnityEnd();') unless @options[:omit_begin_end]
+      output.puts('  return UNITY_END();') unless @options[:omit_begin_end]
     end
     output.puts('}')
   end
 
   def create_h_file(output, filename, tests, testfile_includes, used_mocks)
-    filename = File.basename(filename).gsub(/[-\/\\\.\,\s]/, '_').upcase
+    filename = File.basename(filename).gsub(/[-\/\\.,\s]/, '_').upcase
     output.puts('/* AUTOGENERATED FILE. DO NOT EDIT. */')
     output.puts("#ifndef _#{filename}")
     output.puts("#define _#{filename}\n\n")
@@ -465,10 +580,13 @@ if $0 == __FILE__
     when '-cexception'
       options[:plugins] = [:cexception]
       true
+    when '-externcincludes'
+      options[:externcincludes] = true
+      true
     when /\.*\.ya?ml$/
       options = UnityTestRunnerGenerator.grab_config(arg)
       true
-    when /--(\w+)=\"?(.*)\"?/
+    when /--(\w+)="?(.*)"?/
       options[Regexp.last_match(1).to_sym] = Regexp.last_match(2)
       true
     when /\.*\.(?:hpp|hh|H|h)$/
@@ -499,8 +617,10 @@ if $0 == __FILE__
           '    --suite_setup=""      - code to execute for setup of entire suite',
           '    --suite_teardown=""   - code to execute for teardown of entire suite',
           '    --use_param_tests=1   - enable parameterized tests (disabled by default)',
-          '    --omit_begin_end=1    - omit calls to UnityBegin and UnityEnd (disabled by default)',
-          '    --header_file=""      - path/name of test header file to generate too'].join("\n")
+          '    --omit_begin_end=1    - omit calls to UnityBegin and UNITY_END (disabled by default)',
+          '    --header_file=""      - path/name of test header file to generate too',
+          '    --shuffle_tests=1     - enable shuffling of the test execution order (disabled by default)',
+          '    --rng_seed=1          - seed value for randomization of test execution order'].join("\n")
     exit 1
   end
 

auto/parse_output.rb

@@ -1,3 +1,10 @@
+# =========================================================================
+#   Unity - A Test Framework for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
+
 #============================================================
 #  Author: John Theofanopoulos
 #  A simple parser. Takes the output files generated during the
@@ -14,10 +21,14 @@
 #    - normal output (raw unity)
 #    - fixture output (unity_fixture.h/.c)
 #    - fixture output with verbose flag set ("-v")
+#    - time output flag set (UNITY_INCLUDE_EXEC_TIME define enabled with milliseconds output)
 #
 #    To use this parser use the following command
 #    ruby parseOutput.rb [options] [file]
 #        options: -xml  : produce a JUnit compatible XML file
+#                 -suiteRequiredSuiteName
+#                       : replace default test suite name to
+#                           "RequiredSuiteName" (can be any name)
 #           file: file to scan for results
 #============================================================
 
@@ -26,6 +37,7 @@ class ParseOutput
   def initialize
     # internal data
     @class_name_idx = 0
+    @result_usual_idx = 3
     @path_delim = nil
 
     # xml output related
@@ -33,6 +45,9 @@ class ParseOutput
     @array_list = false
 
     # current suite name and statistics
+    ## testsuite name
+    @real_test_suite_name = 'Unity'
+    ## classname for testcase
     @test_suite = nil
     @total_tests = 0
     @test_passed = 0
@@ -45,6 +60,16 @@ class ParseOutput
     @xml_out = true
   end
 
+  # Set the flag to indicate if there will be an XML output file or not
+  def test_suite_name=(cli_arg)
+    @real_test_suite_name = cli_arg
+    puts "Real test suite name will be '#{@real_test_suite_name}'"
+  end
+
+  def xml_encode_s(str)
+    str.encode(:xml => :attr)
+  end
+
   # If write our output to XML
   def write_xml_output
     output = File.open('report.xml', 'w')
@@ -57,28 +82,28 @@ class ParseOutput
   # Pushes the suite info as xml to the array list, which will be written later
   def push_xml_output_suite_info
     # Insert opening tag at front
-    heading = '<testsuite name="Unity" tests="' + @total_tests.to_s + '" failures="' + @test_failed.to_s + '"' + ' skips="' + @test_ignored.to_s + '">'
+    heading = "<testsuite name=#{xml_encode_s(@real_test_suite_name)} tests=\"#{@total_tests}\" failures=\"#{@test_failed}\" skips=\"#{@test_ignored}\">"
     @array_list.insert(0, heading)
     # Push back the closing tag
     @array_list.push '</testsuite>'
   end
 
   # Pushes xml output data to the array list, which will be written later
-  def push_xml_output_passed(test_name)
-    @array_list.push '    <testcase classname="' + @test_suite + '" name="' + test_name + '"/>'
+  def push_xml_output_passed(test_name, execution_time = 0)
+    @array_list.push "    <testcase classname=#{xml_encode_s(@test_suite)} name=#{xml_encode_s(test_name)} time=#{xml_encode_s((execution_time / 1000.0).to_s)} />"
   end
 
   # Pushes xml output data to the array list, which will be written later
-  def push_xml_output_failed(test_name, reason)
-    @array_list.push '    <testcase classname="' + @test_suite + '" name="' + test_name + '">'
-    @array_list.push '        <failure type="ASSERT FAILED">' + reason + '</failure>'
+  def push_xml_output_failed(test_name, reason, execution_time = 0)
+    @array_list.push "    <testcase classname=#{xml_encode_s(@test_suite)} name=#{xml_encode_s(test_name)} time=#{xml_encode_s((execution_time / 1000.0).to_s)} >"
+    @array_list.push "        <failure type=\"ASSERT FAILED\">#{reason}</failure>"
     @array_list.push '    </testcase>'
   end
 
   # Pushes xml output data to the array list, which will be written later
-  def push_xml_output_ignored(test_name, reason)
-    @array_list.push '    <testcase classname="' + @test_suite + '" name="' + test_name + '">'
-    @array_list.push '        <skipped type="TEST IGNORED">' + reason + '</skipped>'
+  def push_xml_output_ignored(test_name, reason, execution_time = 0)
+    @array_list.push "    <testcase classname=#{xml_encode_s(@test_suite)} name=#{xml_encode_s(test_name)} time=#{xml_encode_s((execution_time / 1000.0).to_s)} >"
+    @array_list.push "        <skipped type=\"TEST IGNORED\">#{reason}</skipped>"
     @array_list.push '    </testcase>'
   end
 
@@ -126,7 +151,7 @@ class ParseOutput
     test_name  = array[1]
     test_suite_verify(class_name)
     reason_array = array[2].split(':')
-    reason = reason_array[-1].lstrip.chomp + ' at line: ' + reason_array[-4]
+    reason = "#{reason_array[-1].lstrip.chomp} at line: #{reason_array[-4]}"
 
     printf "%-40s FAILED\n", test_name
 
@@ -152,21 +177,31 @@ class ParseOutput
 
   # Test was flagged as having passed so format the output
   def test_passed(array)
+    # ':' symbol will be valid in function args now
+    real_method_name = array[@result_usual_idx - 1..-2].join(':')
+    array = array[0..@result_usual_idx - 2] + [real_method_name] + [array[-1]]
+
     last_item = array.length - 1
+    test_time = get_test_time(array[last_item])
     test_name = array[last_item - 1]
     test_suite_verify(array[@class_name_idx])
-    printf "%-40s PASS\n", test_name
+    printf "%-40s PASS %10d ms\n", test_name, test_time
 
     return unless @xml_out
 
-    push_xml_output_passed(test_name) if @xml_out
+    push_xml_output_passed(test_name, test_time) if @xml_out
   end
 
   # Test was flagged as having failed so format the line
   def test_failed(array)
+    # ':' symbol will be valid in function args now
+    real_method_name = array[@result_usual_idx - 1..-3].join(':')
+    array = array[0..@result_usual_idx - 3] + [real_method_name] + array[-2..]
+
     last_item = array.length - 1
+    test_time = get_test_time(array[last_item])
     test_name = array[last_item - 2]
-    reason = array[last_item].chomp.lstrip + ' at line: ' + array[last_item - 3]
+    reason = "#{array[last_item].chomp.lstrip} at line: #{array[last_item - 3]}"
     class_name = array[@class_name_idx]
 
     if test_name.start_with? 'TEST('
@@ -180,14 +215,19 @@ class ParseOutput
     end
 
     test_suite_verify(class_name)
-    printf "%-40s FAILED\n", test_name
+    printf "%-40s FAILED %10d ms\n", test_name, test_time
 
-    push_xml_output_failed(test_name, reason) if @xml_out
+    push_xml_output_failed(test_name, reason, test_time) if @xml_out
   end
 
   # Test was flagged as being ignored so format the output
   def test_ignored(array)
+    # ':' symbol will be valid in function args now
+    real_method_name = array[@result_usual_idx - 1..-3].join(':')
+    array = array[0..@result_usual_idx - 3] + [real_method_name] + array[-2..]
+
     last_item = array.length - 1
+    test_time = get_test_time(array[last_item])
     test_name = array[last_item - 2]
     reason = array[last_item].chomp.lstrip
     class_name = array[@class_name_idx]
@@ -203,9 +243,18 @@ class ParseOutput
     end
 
     test_suite_verify(class_name)
-    printf "%-40s IGNORED\n", test_name
+    printf "%-40s IGNORED %10d ms\n", test_name, test_time
 
-    push_xml_output_ignored(test_name, reason) if @xml_out
+    push_xml_output_ignored(test_name, reason, test_time) if @xml_out
+  end
+
+  # Test time will be in ms
+  def get_test_time(value_with_time)
+    test_time_array = value_with_time.scan(/\((-?\d+.?\d*) ms\)\s*$/).flatten.map do |arg_value_str|
+      arg_value_str.include?('.') ? arg_value_str.to_f : arg_value_str.to_i
+    end
+
+    test_time_array.any? ? test_time_array[0] : 0
   end
 
   # Adjusts the os specific members according to the current path style
@@ -226,7 +275,7 @@ class ParseOutput
   def process(file_name)
     @array_list = []
 
-    puts 'Parsing file: ' + file_name
+    puts "Parsing file: #{file_name}"
 
     @test_passed = 0
     @test_failed = 0
@@ -234,7 +283,8 @@ class ParseOutput
     puts ''
     puts '=================== RESULTS ====================='
     puts ''
-    File.open(file_name).each do |line|
+    # Apply binary encoding. Bad symbols will be unchanged
+    File.open(file_name, 'rb').each do |line|
       # Typical test lines look like these:
       # ----------------------------------------------------
       # 1. normal output:
@@ -288,15 +338,31 @@ class ParseOutput
         line_array.push('No reason given')
         test_ignored(line_array)
         @test_ignored += 1
+      elsif line_array.size >= 4
+        # We will check output from color compilation
+        if line_array[@result_usual_idx..].any? { |l| l.include? 'PASS' }
+          test_passed(line_array)
+          @test_passed += 1
+        elsif line_array[@result_usual_idx..].any? { |l| l.include? 'FAIL' }
+          test_failed(line_array)
+          @test_failed += 1
+        elsif line_array[@result_usual_idx..-2].any? { |l| l.include? 'IGNORE' }
+          test_ignored(line_array)
+          @test_ignored += 1
+        elsif line_array[@result_usual_idx..].any? { |l| l.include? 'IGNORE' }
+          line_array.push("No reason given (#{get_test_time(line_array[@result_usual_idx..])} ms)")
+          test_ignored(line_array)
+          @test_ignored += 1
+        end
       end
       @total_tests = @test_passed + @test_failed + @test_ignored
     end
     puts ''
     puts '=================== SUMMARY ====================='
     puts ''
-    puts 'Tests Passed  : ' + @test_passed.to_s
-    puts 'Tests Failed  : ' + @test_failed.to_s
-    puts 'Tests Ignored : ' + @test_ignored.to_s
+    puts "Tests Passed  : #{@test_passed}"
+    puts "Tests Failed  : #{@test_failed}"
+    puts "Tests Ignored : #{@test_ignored}"
 
     return unless @xml_out
 
@@ -314,6 +380,8 @@ if ARGV.size >= 1
   ARGV.each do |arg|
     if arg == '-xml'
       parse_my_file.set_xml_output
+    elsif arg.start_with?('-suite')
+      parse_my_file.test_suite_name = arg.delete_prefix('-suite')
     else
       parse_my_file.process(arg)
       break

auto/run_test.erb

@@ -1,8 +1,8 @@
 /*=======Test Runner Used To Run Each Test=====*/
-static void run_test(UnityTestFunction func, const char* name, int line_num)
+static void run_test(UnityTestFunction func, const char* name, UNITY_LINE_TYPE line_num)
 {
     Unity.CurrentTestName = name;
-    Unity.CurrentTestLineNumber = line_num;
+    Unity.CurrentTestLineNumber = (UNITY_UINT) line_num;
 #ifdef UNITY_USE_COMMAND_LINE_ARGS
     if (!UnityTestMatches())
         return;
@@ -14,7 +14,7 @@ static void run_test(UnityTestFunction func, const char* name, int line_num)
     if (TEST_PROTECT())
     {
 <% if @options[:plugins].include?(:cexception) %>
-        CEXCEPTION_T e;
+        volatile CEXCEPTION_T e;
         Try {
             <%= @options[:setup_name] %>();
             func();

auto/stylize_as_junit.py

@@ -1,6 +1,15 @@
+#!/usr/bin/env python3
+# =========================================================================
+#   Unity - A Test Framework for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
+
 import sys
 import os
 from glob import glob
+import argparse
 
 from pyparsing import *
 from junit_xml import TestSuite, TestCase
@@ -14,6 +23,7 @@ class UnityTestSummary:
         self.ignored = 0
         self.targets = 0
         self.root = None
+        self.output = None
         self.test_suites = dict()
 
     def run(self):
@@ -37,15 +47,18 @@ class UnityTestSummary:
             entry = entry_one | entry_two
 
             delimiter = Literal(':').suppress()
-            tc_result_line = Group(entry.setResultsName('tc_file_name') + delimiter + entry.setResultsName(
-                'tc_line_nr') + delimiter + entry.setResultsName('tc_name') + delimiter + entry.setResultsName(
-                'tc_status') + Optional(
-                delimiter + entry.setResultsName('tc_msg'))).setResultsName("tc_line")
+            # Format of a result line is `[file_name]:line:test_name:RESULT[:msg]`
+            tc_result_line = Group(ZeroOrMore(entry.setResultsName('tc_file_name'))
+                + delimiter + entry.setResultsName('tc_line_nr')
+                + delimiter + entry.setResultsName('tc_name')
+                + delimiter + entry.setResultsName('tc_status') +
+                Optional(delimiter + entry.setResultsName('tc_msg'))).setResultsName("tc_line")
 
             eol = LineEnd().suppress()
             sol = LineStart().suppress()
             blank_line = sol + eol
 
+            # Format of the summary line is `# Tests # Failures # Ignored`
             tc_summary_line = Group(Word(nums).setResultsName("num_of_tests") + "Tests" + Word(nums).setResultsName(
                 "num_of_fail") + "Failures" + Word(nums).setResultsName("num_of_ignore") + "Ignored").setResultsName(
                 "tc_summary")
@@ -67,7 +80,10 @@ class UnityTestSummary:
                     tmp_tc_line = r['tc_line']
 
                     # get only the file name which will be used as the classname
-                    file_name = tmp_tc_line['tc_file_name'].split('\\').pop().split('/').pop().rsplit('.', 1)[0]
+                    if 'tc_file_name' in tmp_tc_line:
+                        file_name = tmp_tc_line['tc_file_name'].split('\\').pop().split('/').pop().rsplit('.', 1)[0]
+                    else:
+                        file_name = result_file.strip("./")
                     tmp_tc = TestCase(name=tmp_tc_line['tc_name'], classname=file_name)
                     if 'tc_status' in tmp_tc_line:
                         if str(tmp_tc_line['tc_status']) == 'IGNORE':
@@ -96,7 +112,7 @@ class UnityTestSummary:
         for suite_name in self.test_suites:
             ts.append(TestSuite(suite_name, self.test_suites[suite_name]))
 
-        with open('result.xml', 'w') as f:
+        with open(self.output, 'w') as f:
             TestSuite.to_file(f, ts, prettyprint='True', encoding='utf-8')
 
         return self.report
@@ -107,40 +123,39 @@ class UnityTestSummary:
     def set_root_path(self, path):
         self.root = path
 
-    @staticmethod
-    def usage(err_msg=None):
-        print("\nERROR: ")
-        if err_msg:
-            print(err_msg)
-        print("\nUsage: unity_test_summary.py result_file_directory/ root_path/")
-        print("     result_file_directory - The location of your results files.")
-        print("                             Defaults to current directory if not specified.")
-        print("                             Should end in / if specified.")
-        print("     root_path - Helpful for producing more verbose output if using relative paths.")
-        sys.exit(1)
+    def set_output(self, output):
+        self.output = output
 
 
 if __name__ == '__main__':
     uts = UnityTestSummary()
-    try:
-        # look in the specified or current directory for result files
-        if len(sys.argv) > 1:
-            targets_dir = sys.argv[1]
-        else:
-            targets_dir = './'
-        targets = list(map(lambda x: x.replace('\\', '/'), glob(targets_dir + '*.test*')))
-        if len(targets) == 0:
-            raise Exception("No *.testpass or *.testfail files found in '%s'" % targets_dir)
-        uts.set_targets(targets)
+    parser = argparse.ArgumentParser(description=
+        """Takes as input the collection of *.testpass and *.testfail result
+        files, and converts them to a JUnit formatted XML.""")
+    parser.add_argument('targets_dir', metavar='result_file_directory',
+                        type=str, nargs='?', default='./',
+                        help="""The location of your results files.
+                        Defaults to current directory if not specified.""")
+    parser.add_argument('root_path', nargs='?',
+                        default='os.path.split(__file__)[0]',
+                        help="""Helpful for producing more verbose output if
+                        using relative paths.""")
+    parser.add_argument('--output', '-o', type=str, default="result.xml",
+                        help="""The name of the JUnit-formatted file (XML).""")
+    args = parser.parse_args()
 
-        # set the root path
-        if len(sys.argv) > 2:
-            root_path = sys.argv[2]
-        else:
-            root_path = os.path.split(__file__)[0]
-        uts.set_root_path(root_path)
+    if args.targets_dir[-1] != '/':
+        args.targets_dir+='/'
+    targets = list(map(lambda x: x.replace('\\', '/'), glob(args.targets_dir + '*.test*')))
+    if len(targets) == 0:
+        raise Exception("No *.testpass or *.testfail files found in '%s'" % args.targets_dir)
+    uts.set_targets(targets)
 
-        # run the summarizer
-        print(uts.run())
-    except Exception as e:
-        UnityTestSummary.usage(e)
+    # set the root path
+    uts.set_root_path(args.root_path)
+
+    # set output
+    uts.set_output(args.output)
+
+    # run the summarizer
+    print(uts.run())

auto/stylize_as_junit.rb

@@ -1,14 +1,16 @@
-#!/usr/bin/ruby
-#
-# unity_to_junit.rb
-#
+#!/usr/bin/env ruby
+# =========================================================================
+#   Unity - A Test Framework for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
+
 require 'fileutils'
 require 'optparse'
 require 'ostruct'
 require 'set'
 
-require 'pp'
-
 VERSION = 1.0
 
 class ArgvParser
@@ -99,7 +101,7 @@ class UnityToJUnit
       test_file = if test_file_str.length < 2
                     result_file
                   else
-                    test_file_str[0] + ':' + test_file_str[1]
+                    "#{test_file_str[0]}:#{test_file_str[1]}"
                   end
       result_output[:source][:path] = File.dirname(test_file)
       result_output[:source][:file] = File.basename(test_file)

auto/test_file_filter.rb

@@ -1,10 +1,11 @@
-# ==========================================
-#   Unity Project - A Test Framework for C
-#   Copyright (c) 2007 Mike Karlesky, Mark VanderVoord, Greg Williams
-#   [Released under MIT License. Please refer to license.txt for details]
-# ==========================================
+# =========================================================================
+#   Unity - A Test Framework for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
 
-require'yaml'
+require_relative 'yaml_helper'
 
 module RakefileHelpers
   class TestFileFilter
@@ -12,9 +13,11 @@ module RakefileHelpers
       @all_files = all_files
 
       return unless @all_files
-      return unless File.exist?('test_file_filter.yml')
 
-      filters = YAML.load_file('test_file_filter.yml')
+      file = 'test_file_filter.yml'
+      return unless File.exist?(file)
+
+      filters = YamlHelper.load_file(file)
       @all_files = filters[:all_files]
       @only_files = filters[:only_files]
       @exclude_files = filters[:exclude_files]

auto/type_sanitizer.rb

@@ -1,6 +1,13 @@
+# =========================================================================
+#   Unity - A Test Framework for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
+
 module TypeSanitizer
   def self.sanitize_c_identifier(unsanitized)
     # convert filename to valid C identifier by replacing invalid chars with '_'
-    unsanitized.gsub(/[-\/\\\.\,\s]/, '_')
+    unsanitized.gsub(/[-\/\\.,\s]/, '_')
   end
 end

auto/unity_test_summary.py

@@ -1,10 +1,11 @@
-#! python3
-# ==========================================
-#   Unity Project - A Test Framework for C
-#   Copyright (c) 2015 Alexander Mueller / XelaRellum@web.de
-#   [Released under MIT License. Please refer to license.txt for details]
-#   Based on the ruby script by  Mike Karlesky, Mark VanderVoord, Greg Williams
-# ==========================================
+#!/usr/bin/env python3
+# =========================================================================
+#   Unity - A Test Framework for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
+
 import sys
 import os
 import re

auto/unity_test_summary.rb

@@ -1,10 +1,11 @@
-# ==========================================
-#   Unity Project - A Test Framework for C
-#   Copyright (c) 2007 Mike Karlesky, Mark VanderVoord, Greg Williams
-#   [Released under MIT License. Please refer to license.txt for details]
-# ==========================================
+#!/usr/bin/env ruby
+# =========================================================================
+#   Unity - A Test Framework for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
 
-# !/usr/bin/ruby
 #
 # unity_test_summary.rb
 #
@@ -86,7 +87,11 @@ class UnityTestSummary
   def get_details(_result_file, lines)
     results = { failures: [], ignores: [], successes: [] }
     lines.each do |line|
-      _src_file, _src_line, _test_name, status, _msg = line.split(/:/)
+      status_match = line.match(/^[^:]+:[^:]+:\w+(?:\([^)]*\))?:([^:]+):?/)
+      next unless status_match
+
+      status = status_match.captures[0]
+
       line_out = (@root && (@root != 0) ? "#{@root}#{line}" : line).gsub(/\//, '\\')
       case status
       when 'IGNORE' then results[:ignores]   << line_out
@@ -108,7 +113,7 @@ if $0 == __FILE__
 
   # parse out the command options
   opts, args = ARGV.partition { |v| v =~ /^--\w+/ }
-  opts.map! { |v| v[2..-1].to_sym }
+  opts.map! { |v| v[2..].to_sym }
 
   # create an instance to work with
   uts = UnityTestSummary.new(opts)
@@ -124,7 +129,7 @@ if $0 == __FILE__
     uts.targets = results
 
     # set the root path
-    args[1] ||= Dir.pwd + '/'
+    args[1] ||= "#{Dir.pwd}/"
     uts.root = ARGV[1]
 
     # run the summarizer

auto/yaml_helper.rb

@@ -0,0 +1,23 @@
+# =========================================================================
+#   Unity - A Test Framework for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
+
+require 'yaml'
+
+module YamlHelper
+  def self.load(body)
+    if YAML.respond_to?(:unsafe_load)
+      YAML.unsafe_load(body)
+    else
+      YAML.load(body)
+    end
+  end
+
+  def self.load_file(file)
+    body = File.read(file)
+    self.load(body)
+  end
+end

docs/CODE_OF_CONDUCT.md

@@ -0,0 +1,138 @@
+
+# ThrowTheSwitch.org Code of Conduct
+
+Thank you for participating in a ThrowTheSwitch.org community project! We want
+this to continue to be a warm and inviting place for everyone to share ideas
+and get help. To accomplish this goal, we've developed this Code of Conduct.
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our
+community a harassment-free experience for everyone, regardless of age, body
+size, visible or invisible disability, ethnicity, sex characteristics, gender
+identity and expression, level of experience, education, socio-economic status,
+nationality, personal appearance, race, caste, color, religion, or sexual
+identity and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming,
+diverse, inclusive, and healthy community.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our
+community include:
+
+* Demonstrating empathy and kindness toward other people
+* Being respectful of differing opinions, viewpoints, and experiences
+* Giving and gracefully accepting constructive feedback
+* Accepting responsibility and apologizing to those affected by our mistakes,
+  and learning from the experience
+* Focusing on what is best not just for us as individuals, but for the overall
+  community
+
+Examples of unacceptable behavior include:
+
+* The use of sexualized language or imagery, and sexual attention or advances of
+  any kind
+* Trolling, insulting or derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or email address,
+  without their explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Enforcement Responsibilities
+
+Community leaders are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any behavior that they deem inappropriate, threatening, offensive,
+or harmful.
+
+Community leaders have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, and will communicate reasons for moderation
+decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public spaces.
+Examples of representing our community include using an official email address,
+posting via an official social media account, or acting as an appointed
+representative at an online or offline event.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported to the community leaders responsible for enforcement at
+hello@thingamabyte.com.
+
+All complaints will be reviewed and investigated promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of the
+reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining
+the consequences for any action they deem in violation of this Code of Conduct:
+
+### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior deemed
+unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders, providing
+clarity around the nature of the violation and an explanation of why the
+behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community Impact**: A violation through a single incident or series of
+actions.
+
+**Consequence**: A warning with consequences for continued behavior. No
+interaction with the people involved, including unsolicited interaction with
+those enforcing the Code of Conduct, for a specified period of time. This
+includes avoiding interactions in community spaces as well as external channels
+like social media. Violating these terms may lead to a temporary or permanent
+ban.
+
+### 3. Temporary Ban
+
+**Community Impact**: A serious violation of community standards, including
+sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public
+communication with the community for a specified period of time. No public or
+private interaction with the people involved, including unsolicited interaction
+with those enforcing the Code of Conduct, is allowed during this period.
+Violating these terms may lead to a permanent ban.
+
+### 4. Permanent Ban
+
+**Community Impact**: Demonstrating a pattern of violation of community
+standards, including sustained inappropriate behavior, harassment of an
+individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within the
+community.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 2.1, available at
+[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1].
+
+Community Impact Guidelines were inspired by
+[Mozilla's code of conduct enforcement ladder][Mozilla CoC].
+
+For answers to common questions about this code of conduct, see the FAQ at
+[https://www.contributor-covenant.org/faq][FAQ]. Translations are available at
+[https://www.contributor-covenant.org/translations][translations].
+
+[homepage]: https://www.contributor-covenant.org
+[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html
+[Mozilla CoC]: https://github.com/mozilla/diversity
+[FAQ]: https://www.contributor-covenant.org/faq
+[translations]: https://www.contributor-covenant.org/translations

docs/CONTRIBUTING.md

@@ -0,0 +1,238 @@
+# Contributing to a ThrowTheSwitch.org Project
+
+👍🎉 _First off, thanks for taking the time to contribute!_ 🎉👍
+
+The following is a set of guidelines for contributing to any of ThrowTheSwitch.org's projects or the website itself, hosted at throwtheswitch.org or ThrowTheSwitch's organization on GitHub. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.
+
+### Table Of Contents
+
+- [Code of Conduct](#book-code-of-conduct)
+- [Asking Questions](#bulb-asking-questions)
+- [Opening an Issue](#inbox_tray-opening-an-issue)
+- [Feature Requests](#love_letter-feature-requests)
+- [Triaging Issues](#mag-triaging-issues)
+- [Submitting Pull Requests](#repeat-submitting-pull-requests)
+- [Writing Commit Messages](#memo-writing-commit-messages)
+- [Code Review](#white_check_mark-code-review)
+- [Coding Style](#nail_care-coding-style)
+- [Certificate of Origin](#medal_sports-certificate-of-origin)
+- [Credits](#pray-credits)
+
+## :book: Code of Conduct
+
+Please review our [Code of Conduct](CODE_OF_CONDUCT.md). It is in effect at all times. We expect it to be honored by everyone who contributes to this project. Be a Good Human!
+
+## :bulb: Asking Questions
+
+> **Note:** Please don't file an issue to ask a question. We have an official forum where the community chimes in with helpful advice if you have questions.
+
+* [ThrowTheSwitch Forums](https://throwtheswitch.org/forums)
+
+### What should I know before I get started?
+
+ThrowTheSwitch hosts a number of open source projects — Ceedling is the entrypoint for many users. Ceedling is actually built upon the foundation of Unity Test (a flexible C testing framework) and CMock (a mocking tool for C) and it coordinates many other open source and proprietary tools. Please do your best to focus your ideas and questions at the correct tool. We'll do our best to help you find your way, but there will be times where we'll have to direct your attention to another subtool.
+
+Here are some of the main projects hosted by ThrowTheSwitch.org:
+
+ - [Ceedling](https://www.github.com/throwtheswitch/ceedling) -- Build coordinator for testing C applications, especially embedded C (and optionally your release build too!)
+ - [CMock](https://www.github.com/throwtheswitch/cmock) -- Mocking tool for automatically creating stubs, mocks, and skeletons in C
+ - [Unity](https://www.github.com/throwtheswitch/unity) -- Unit Testing framework for C, specially embedded C.
+ - [MadScienceLabDocker](https://www.github.com/throwtheswitch/madsciencelabdocker) -- Docker image giving you a shortcut to getting running with Ceedling
+ - [CException](https://www.github.com/throwtheswitch/cexception) -- An exception framework for using simple exceptions in C.
+
+There are many more, but this list should be a good starting point.
+
+## :inbox_tray: Opening an Issue
+
+Before [creating an issue](https://help.github.com/en/github/managing-your-work-on-github/creating-an-issue), check if you are using the latest version of the project. If you are not up-to-date, see if updating fixes your issue first.
+
+### :beetle: Bug Reports and Other Issues
+
+A great way to contribute to the project is to send a detailed issue when you encounter a problem. We always appreciate a well-written, thorough bug report. :v:
+
+In short, since you are most likely a developer, **provide a ticket that you would like to receive**.
+
+- **Review the documentation** before opening a new issue.
+
+- **Do not open a duplicate issue!** Search through existing issues to see if your issue has previously been reported. If your issue exists, comment with any additional information you have. You may simply note "I have this problem too", which helps prioritize the most common problems and requests. 
+
+- **Prefer using [reactions](https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/)**, not comments, if you simply want to "+1" an existing issue.
+
+- **Fully complete the provided issue template.** The bug report template requests all the information we need to quickly and efficiently address your issue. Be clear, concise, and descriptive. Provide as much information as you can, including steps to reproduce, stack traces, compiler errors, library versions, OS versions, and screenshots (if applicable).
+
+- **Use [GitHub-flavored Markdown](https://help.github.com/en/github/writing-on-github/basic-writing-and-formatting-syntax).** Especially put code blocks and console outputs in backticks (```). This improves readability.
+
+## :seedling: Feature Requests
+
+Feature requests are welcome! We don't have all the answers and we truly love the collaborative experience of building software together! That being said, we cannot guarantee your request will be accepted. We want to avoid [feature creep](https://en.wikipedia.org/wiki/Feature_creep). Your idea may be great, but also out-of-scope for the project. If accepted, we'll do our best to tackle it in a timely manner, but cannot make any commitments regarding the timeline for implementation and release. However, you are welcome to submit a pull request to help!
+
+- **Please don't open a duplicate feature request.** Search for existing feature requests first. If you find your feature (or one very similar) previously requested, comment on that issue.
+
+- **Fully complete the provided issue template.** The feature request template asks for all necessary information for us to begin a productive conversation. 
+
+- Be precise about the proposed outcome of the feature and how it relates to existing features. Include implementation details if possible.
+
+## :mag: Triaging Issues
+
+You can triage issues which may include reproducing bug reports or asking for additional information, such as version numbers or reproduction instructions. Any help you can provide to quickly resolve an issue is very much appreciated!
+
+## :repeat: Submitting Pull Requests
+
+We **love** pull requests! Before [forking the repo](https://help.github.com/en/github/getting-started-with-github/fork-a-repo) and [creating a pull request](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/proposing-changes-to-your-work-with-pull-requests) for non-trivial changes, it is usually best to first open an issue to discuss the changes, or discuss your intended approach for solving the problem in the comments for an existing issue.
+
+For most contributions, after your first pull request is accepted and merged, you will be [invited to the project](https://help.github.com/en/github/setting-up-and-managing-your-github-user-account/inviting-collaborators-to-a-personal-repository) and given **push access**. :tada:
+
+*Note: All contributions will be licensed under the project's license.*
+
+- **Smaller is better.** Submit **one** pull request per bug fix or feature. A pull request should contain isolated changes pertaining to a single bug fix or feature implementation. **Do not** refactor or reformat code that is unrelated to your change. It is better to **submit many small pull requests** rather than a single large one. Enormous pull requests will take enormous amounts of time to review, or may be rejected altogether. 
+
+- **Coordinate bigger changes.** For large and non-trivial changes, open an issue to discuss a strategy with the maintainers. Otherwise, you risk doing a lot of work for nothing!
+
+- **Prioritize understanding over cleverness.** Write code clearly and concisely. Remember that source code usually gets written once and read often. Ensure the code is clear to the reader. The purpose and logic should be obvious to a reasonably skilled developer, otherwise you should add a comment that explains it.
+
+- **Follow existing coding style and conventions.** Keep your code consistent with the style, formatting, and conventions in the rest of the code base. When possible, these will be enforced with a linter. Consistency makes it easier to review and modify in the future.
+
+- **Include test coverage.** Add unit tests when possible. Follow existing patterns for implementing tests.
+
+- **Update the example project** if one exists to exercise any new functionality you have added.
+
+- **Add documentation.** Document your changes with code doc comments or in existing guides.
+
+- **Update the CHANGELOG** for all enhancements and bug fixes. Include the corresponding issue number if one exists, and your GitHub username. (example: "- Fixed crash in profile view. #123 @jessesquires")
+
+- **Use the repo's default branch.** Branch from and [submit your pull request](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request-from-a-fork) to the repo's default branch. Usually this is `main`, but it could be `dev`, `develop`, or `master`.
+
+- **[Resolve any merge conflicts](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-on-github)** that occur.
+
+- **Promptly address any CI failures**. If your pull request fails to build or pass tests, please push another commit to fix it. 
+
+- When writing comments, use properly constructed sentences, including punctuation.
+
+- Use spaces, not tabs.
+
+## :memo: Writing Commit Messages
+
+Please [write a great commit message](https://chris.beams.io/posts/git-commit/).
+
+1. Separate subject from body with a blank line
+1. Limit the subject line to 50 characters
+1. Capitalize the subject line
+1. Do not end the subject line with a period
+1. Wrap the body at _about_ 72 characters
+1. Use the body to explain **why**, *not what and how* (the code shows that!)
+1. If applicable, prefix the title with the relevant component name or emoji (see below. examples: "[Docs] Fix typo", "[Profile] Fix missing avatar")
+
+```
+:palm_tree: Summary of Amazing Feature Here
+
+Add a more detailed explanation here, if necessary. Possibly give 
+some background about the issue being fixed, etc. The body of the 
+commit message can be several paragraphs. Further paragraphs come 
+after blank lines and please do proper word-wrap.
+
+Wrap it to about 72 characters or so. In some contexts, 
+the first line is treated as the subject of the commit and the 
+rest of the text as the body. The blank line separating the summary 
+from the body is critical (unless you omit the body entirely); 
+various tools like `log`, `shortlog` and `rebase` can get confused 
+if you run the two together.
+
+Explain the problem that this commit is solving. Focus on why you
+are making this change as opposed to how or what. The code explains 
+how or what. Reviewers and your future self can read the patch, 
+but might not understand why a particular solution was implemented.
+Are there side effects or other unintuitive consequences of this
+change? Here's the place to explain them.
+
+ - Bullet points are awesome, too
+
+ - A hyphen should be used for the bullet, preceded
+   by a single space, with blank lines in between
+
+Note the fixed or relevant GitHub issues at the end:
+
+Resolves: #123
+See also: #456, #789
+```
+
+## :heart: Who Loves Emoji?
+
+Commit comments, Issues, Feature Requests... they can all use a little sprucing up, right? Consider using the following emoji for a mix of function and :sparkles: dazzle!
+
+  - actions
+    - :seedling: `:seedling:` (or other plants) when growing new features. Choose your fav! :cactus: :herb: :evergreen_tree: :palm_tree: :deciduous_tree: :blossom: 
+    - :art: `:art:` when improving the format/structure of the code
+    - :racehorse: `:racehorse:` when improving performance
+    - :non-potable_water: `:non-potable_water:` when plugging memory leaks
+    - :memo: `:memo:` when writing docs
+    - :bug: `:bug:` (or other insects) when fixing a bug. Maybe :beetle: :ant: or :honeybee: ?
+    - :fire: `:fire:` when removing code or files
+    - :green_heart: `:green_heart:` when fixing the CI build
+    - :white_check_mark: `:white_check_mark:` when adding tests
+    - :lock: `:lock:` when dealing with security
+    - :arrow_up: `:arrow_up:` when upgrading dependencies
+    - :arrow_down: `:arrow_down:` when downgrading dependencies
+    - :shirt: `:shirt:` when removing linter warnings
+
+  - platforms
+    - :penguin: `:penguin:` when fixing something on Linux
+    - :apple: `:apple:` when fixing something on macOS
+    - :checkered_flag: `:checkered_flag:` when fixing something on Windows
+
+## :white_check_mark: Code Review
+
+- **Review the code, not the author.** Look for and suggest improvements without disparaging or insulting the author. Provide actionable feedback and explain your reasoning.
+
+- **You are not your code.** When your code is critiqued, questioned, or constructively criticized, remember that you are not your code. Do not take code review personally.
+
+- **Always do your best.** No one writes bugs on purpose. Do your best, and learn from your mistakes.
+
+- Kindly note any violations to the guidelines specified in this document. 
+
+## :violin: Coding Style
+
+Consistency is the most important. Following the existing style, formatting, and naming conventions of the file you are modifying and of the overall project. Failure to do so will result in a prolonged review process that has to focus on updating the superficial aspects of your code, rather than improving its functionality and performance.
+
+For example, if all private properties are prefixed with an underscore `_`, then new ones you add should be prefixed in the same way. Or, if methods are named using camelcase, like `thisIsMyNewMethod`, then do not diverge from that by writing `this_is_my_new_method`. You get the idea. If in doubt, please ask or search the codebase for something similar.
+
+When possible, style and format will be enforced with a linter.
+
+### C Styleguide
+
+C code is linted with [AStyle](https://astyle.sourceforge.net/).
+
+### Ruby Styleguide
+
+Ruby code is linted with [Rubocop](https://github.com/rubocop/rubocop)
+
+## :medal_sports: Certificate of Origin
+
+*Developer's Certificate of Origin 1.1*
+
+By making a contribution to this project, I certify that:
+
+> 1. The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or
+> 1. The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or
+> 1. The contribution was provided directly to me by some other person who certified (1), (2) or (3) and I have not modified it.
+> 1. I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.
+
+## [No Brown M&M's](https://en.wikipedia.org/wiki/Van_Halen#Contract_riders)
+
+If you are reading this, bravo dear user and (hopefully) contributor for making it this far! You are awesome. :100: 
+
+To confirm that you have read this guide and are following it as best as possible, **include this emoji at the top** of your issue or pull request: :pineapple: `:pineapple:`
+
+## :pray: Credits
+
+Written by [@jessesquires](https://github.com/jessesquires). Lovingly adapted to ThrowTheSwitch.org by [@mvandervoord](https://github.com/mvandervoord).
+
+**Please feel free to adopt this guide in your own projects. Fork it wholesale or remix it for your needs.**
+
+*Many of the ideas and prose for the statements in this document were based on or inspired by work from the following communities:*
+
+- [Alamofire](https://github.com/Alamofire/Alamofire/blob/master/CONTRIBUTING.md)
+- [CocoaPods](https://github.com/CocoaPods/CocoaPods/blob/master/CONTRIBUTING.md)
+- [Docker](https://github.com/moby/moby/blob/master/CONTRIBUTING.md)
+- [Linux](https://elinux.org/Developer_Certificate_Of_Origin)
+
+*We commend them for their efforts to facilitate collaboration in their projects.*

docs/MesonGeneratorRunner.md

@@ -0,0 +1,18 @@
+# Meson Generator - Test Runner
+
+One of the really nice things about using Unity with Ceedling is that Ceedling takes care of generating all of the test runners automatically. If you're not using Ceedling though, you'll need to do this yourself.
+
+The way this is done in Unity is via a Ruby script called `generate_test_runner.rb`. When given a test file such as `test_example.c`, the script will generate `test_example_Runner.c`, which provides the `main` method and some other useful plumbing.
+
+So that you don't have to run this by hand, a Meson generator is provided to generate the runner automatically for you. Generally with Meson, you would use Unity as a subproject and you'd want to access the generator from the parent.
+
+For example, to get the generator you can use:
+
+    unity_proj = subproject('unity')
+    runner_gen = unity_proj.get_variable('gen_test_runner')
+
+Once you have the generator you need to pass it the absolute path of your test file. This seems to be a bug in how the paths work with subprojects in Meson. You can get the full path with `meson.source_root()`, so you could do:
+
+    test_runner = meson.source_root() / 'test/test_example.c'
+
+You can then include `test_runner` as a normal dependency to your builds. Meson will create the test runner in a private directory for each build target. It's only meant to be used as part of the build, so if you need to refer to the runner after the build, you won't be able to use the generator.

docs/ThrowTheSwitchCodingStandard.md

@@ -1,136 +1,116 @@
 # ThrowTheSwitch.org Coding Standard
 
-Hi. Welcome to the coding standard for ThrowTheSwitch.org. For the most part,
-we try to follow these standards to unify our contributors' code into a cohesive
-unit (puns intended). You might find places where these standards aren't
-followed. We're not perfect. Please be polite where you notice these discrepancies
-and we'll try to be polite when we notice yours.
+Hi.
+Welcome to the coding standard for ThrowTheSwitch.org.
+For the most part, we try to follow these standards to unify our contributors' code into a cohesive unit (puns intended).
+You might find places where these standards aren't followed.
+We're not perfect. Please be polite where you notice these discrepancies and we'll try to be polite when we notice yours.
 
 ;)
 
-
 ## Why Have A Coding Standard?
 
-Being consistent makes code easier to understand. We've tried to keep
-our standard simple because we also believe that we can only expect someone to
-follow something that is understandable. Please do your best.
-
+Being consistent makes code easier to understand.
+We've tried to keep our standard simple because we also believe that we can only expect someone to follow something that is understandable.
+Please do your best.
 
 ## Our Philosophy
 
-Before we get into details on syntax, let's take a moment to talk about our
-vision for these tools. We're C developers and embedded software developers.
-These tools are great to test any C code, but catering to embedded software has
-made us more tolerant of compiler quirks. There are a LOT of quirky compilers
-out there. By quirky I mean "doesn't follow standards because they feel like
-they have a license to do as they wish."
+Before we get into details on syntax, let's take a moment to talk about our vision for these tools.
+We're C developers and embedded software developers.
+These tools are great to test any C code, but catering to embedded software made us more tolerant of compiler quirks.
+There are a LOT of quirky compilers out there.
+By quirky I mean "doesn't follow standards because they feel like they have a license to do as they wish."
 
-Our philosophy is "support every compiler we can". Most often, this means that
-we aim for writing C code that is standards compliant (often C89... that seems
-to be a sweet spot that is almost always compatible). But it also means these
-tools are tolerant of things that aren't common. Some that aren't even
-compliant. There are configuration options to override the size of standard
-types. There are configuration options to force Unity to not use certain
-standard library functions. A lot of Unity is configurable and we have worked
-hard to make it not TOO ugly in the process.
+Our philosophy is "support every compiler we can".
+Most often, this means that we aim for writing C code that is standards compliant (often C89... that seems to be a sweet spot that is almost always compatible).
+But it also means these tools are tolerant of things that aren't common.
+Some that aren't even compliant.
+There are configuration options to override the size of standard types.
+There are configuration options to force Unity to not use certain standard library functions.
+A lot of Unity is configurable and we have worked hard to make it not TOO ugly in the process.
 
-Similarly, our tools that parse C do their best. They aren't full C parsers
-(yet) and, even if they were, they would still have to accept non-standard
-additions like gcc extensions or specifying `@0x1000` to force a variable to
-compile to a particular location. It's just what we do, because we like
-everything to Just Work™.
-
-Speaking of having things Just Work™, that's our second philosophy. By that, we
-mean that we do our best to have EVERY configuration option have a logical
-default. We believe that if you're working with a simple compiler and target,
-you shouldn't need to configure very much... we try to make the tools guess as
-much as they can, but give the user the power to override it when it's wrong.
+Similarly, our tools that parse C do their best.
+They aren't full C parsers (yet) and, even if they were, they would still have to accept non-standard additions like gcc extensions or specifying `@0x1000` to force a variable to compile to a particular location.
+It's just what we do, because we like everything to Just Work™.
 
+Speaking of having things Just Work™, that's our second philosophy.
+By that, we mean that we do our best to have EVERY configuration option have a logical default.
+We believe that if you're working with a simple compiler and target, you shouldn't need to configure very much... we try to make the tools guess as much as they can, but give the user the power to override it when it's wrong.
 
 ## Naming Things
 
-Let's talk about naming things. Programming is all about naming things. We name
-files, functions, variables, and so much more. While we're not always going to
-find the best name for something, we actually put a bit of effort into
-finding *What Something WANTS to be Called*™.
+Let's talk about naming things.
+Programming is all about naming things.
+We name files, functions, variables, and so much more.
+While we're not always going to find the best name for something, we actually put a bit of effort into finding *What Something WANTS to be Called*™.
+
+When naming things, we follow this hierarchy, the first being the most important to us (but we do all four when possible):
 
-When naming things, we follow this hierarchy, the first being the
-most important to us (but we do all four when possible):
 1. Readable
 2. Descriptive
 3. Consistent
 4. Memorable
 
+### Readable
 
-#### Readable
+We want to read our code.
+This means we like names and flow that are more naturally read.
+We try to avoid double negatives.
+We try to avoid cryptic abbreviations (sticking to ones we feel are common).
 
-We want to read our code. This means we like names and flow that are more
-naturally read. We try to avoid double negatives. We try to avoid cryptic
-abbreviations (sticking to ones we feel are common).
-
-
-#### Descriptive
+### Descriptive
 
 We like descriptive names for things, especially functions and variables.
-Finding the right name for something is an important endeavor. You might notice
-from poking around our code that this often results in names that are a little
-longer than the average. Guilty. We're okay with a bit more typing if it
-means our code is easier to understand.
+Finding the right name for something is an important endeavour.
+You might notice from poking around our code that this often results in names that are a little longer than the average.
+Guilty.
+We're okay with a bit more typing if it means our code is easier to understand.
 
-There are two exceptions to this rule that we also stick to as religiously as
-possible:
+There are two exceptions to this rule that we also stick to as religiously as possible:
 
-First, while we realize hungarian notation (and similar systems for encoding
-type information into variable names) is providing a more descriptive name, we
-feel that (for the average developer) it takes away from readability and is to be avoided.
+First, while we realize hungarian notation (and similar systems for encoding type information into variable names) is providing a more descriptive name, we feel that (for the average developer) it takes away from readability and is to be avoided.
 
-Second, loop counters and other local throw-away variables often have a purpose
-which is obvious. There's no need, therefore, to get carried away with complex
-naming. We find i, j, and k are better loop counters than loopCounterVar or
-whatnot. We only break this rule when we see that more description could improve
-understanding of an algorithm.
+Second, loop counters and other local throw-away variables often have a purpose which is obvious.
+There's no need, therefore, to get carried away with complex naming.
+We find i, j, and k are better loop counters than loopCounterVar or whatnot.
+We only break this rule when we see that more description could improve understanding of an algorithm.
 
+### Consistent
 
-#### Consistent
+We like consistency, but we're not really obsessed with it.
+We try to name our configuration macros in a consistent fashion... you'll notice a repeated use of UNITY_EXCLUDE_BLAH or UNITY_USES_BLAH macros.
+This helps users avoid having to remember each macro's details.
 
-We like consistency, but we're not really obsessed with it. We try to name our
-configuration macros in a consistent fashion... you'll notice a repeated use of
-UNITY_EXCLUDE_BLAH or UNITY_USES_BLAH macros. This helps users avoid having to
-remember each macro's details.
-
-
-#### Memorable
-
-Where ever it doesn't violate the above principles, we try to apply memorable
-names. Sometimes this means using something that is simply descriptive, but
-often we strive for descriptive AND unique... we like quirky names that stand
-out in our memory and are easier to search for. Take a look through the file
-names in Ceedling and you'll get a good idea of what we are talking about here.
-Why use preprocess when you can use preprocessinator? Or what better describes a
-module in charge of invoking tasks during releases than release_invoker? Don't
-get carried away. The names are still descriptive and fulfill the above
-requirements, but they don't feel stale.
+### Memorable
 
+Where ever it doesn't violate the above principles, we try to apply memorable names.
+Sometimes this means using something that is simply descriptive, but often we strive for descriptive AND unique... we like quirky names that stand out in our memory and are easier to search for.
+Take a look through the file names in Ceedling and you'll get a good idea of what we are talking about here.
+Why use preprocess when you can use preprocessinator?
+Or what better describes a module in charge of invoking tasks during releases than release_invoker?
+Don't get carried away.
+The names are still descriptive and fulfill the above requirements, but they don't feel stale.
 
 ## C and C++ Details
 
-We don't really want to add to the style battles out there. Tabs or spaces?
-How many spaces? Where do the braces go? These are age-old questions that will
-never be answered... or at least not answered in a way that will make everyone
-happy.
+We don't really want to add to the style battles out there.
+Tabs or spaces?
+How many spaces?
+Where do the braces go?
+These are age-old questions that will never be answered... or at least not answered in a way that will make everyone happy.
 
-We've decided on our own style preferences. If you'd like to contribute to these
-projects (and we hope that you do), then we ask if you do your best to follow
-the same. It will only hurt a little. We promise.
+We've decided on our own style preferences.
+If you'd like to contribute to these projects (and we hope that you do), then we ask if you do your best to follow the same.
+It will only hurt a little. We promise.
 
+### Whitespace in C/C++
 
-#### Whitespace
-
-Our C-style is to use spaces and to use 4 of them per indent level. It's a nice
-power-of-2 number that looks decent on a wide-screen. We have no more reason
-than that. We break that rule when we have lines that wrap (macros or function
-arguments or whatnot). When that happens, we like to indent further to line
-things up in nice tidy columns.
+Our C-style is to use spaces and to use 4 of them per indent level.
+It's a nice power-of-2 number that looks decent on a wide-screen.
+We have no more reason than that.
+We break that rule when we have lines that wrap (macros or function arguments or whatnot).
+When that happens, we like to indent further to line things up in nice tidy columns.
 
 ```C
     if (stuff_happened)
@@ -139,8 +119,7 @@ things up in nice tidy columns.
     }
 ```
 
-
-#### Case
+### Case in C/C++
 
 - Files - all lower case with underscores.
 - Variables - all lower case with underscores
@@ -149,12 +128,12 @@ things up in nice tidy columns.
 - Functions - camel cased. Usually named ModuleName_FuncName
 - Constants and Globals - camel cased.
 
+### Braces in C/C++
 
-#### Braces
-
-The left brace is on the next line after the declaration. The right brace is
-directly below that. Everything in between in indented one level. If you're
-catching an error and you have a one-line, go ahead and to it on the same line.
+The left brace is on the next line after the declaration.
+The right brace is directly below that.
+Everything in between in indented one level.
+If you're catching an error and you have a one-line, go ahead and to it on the same line.
 
 ```C
     while (blah)
@@ -163,32 +142,32 @@ catching an error and you have a one-line, go ahead and to it on the same line.
     }
 ```
 
+### Comments in C/C++
 
-#### Comments
-
-Do you know what we hate? Old-school C block comments. BUT, we're using them
-anyway. As we mentioned, our goal is to support every compiler we can,
-especially embedded compilers. There are STILL C compilers out there that only
-support old-school block comments. So that is what we're using. We apologize. We
-think they are ugly too.
-
+Do you know what we hate?
+Old-school C block comments.
+BUT, we're using them anyway.
+As we mentioned, our goal is to support every compiler we can, especially embedded compilers.
+There are STILL C compilers out there that only support old-school block comments.
+So that is what we're using.
+We apologize.
+We think they are ugly too.
 
 ## Ruby Details
 
-Is there really such thing as a Ruby coding standard? Ruby is such a free form
-language, it seems almost sacrilegious to suggest that people should comply to
-one method! We'll keep it really brief!
+Is there really such thing as a Ruby coding standard?
+Ruby is such a free form language, it seems almost sacrilegious to suggest that people should comply to one method!
+We'll keep it really brief!
 
+### Whitespace in Ruby
 
-#### Whitespace
+Our Ruby style is to use spaces and to use 2 of them per indent level.
+It's a nice power-of-2 number that really grooves with Ruby's compact style.
+We have no more reason than that.
+We break that rule when we have lines that wrap.
+When that happens, we like to indent further to line things up in nice tidy columns.
 
-Our Ruby style is to use spaces and to use 2 of them per indent level. It's a
-nice power-of-2 number that really grooves with Ruby's compact style. We have no
-more reason than that. We break that rule when we have lines that wrap. When
-that happens, we like to indent further to line things up in nice tidy columns.
-
-
-#### Case
+### Case in Ruby
 
 - Files - all lower case with underscores.
 - Variables - all lower case with underscores
@@ -196,11 +175,13 @@ that happens, we like to indent further to line things up in nice tidy columns.
 - Functions - all lower case with underscores
 - Constants - all upper case with underscores
 
-
 ## Documentation
 
-Egad. Really? We use mark down and we like pdf files because they can be made to
-look nice while still being portable. Good enough?
+Egad.
+Really?
+We use markdown and we like PDF files because they can be made to look nice while still being portable.
+Good enough?
 
+*Find The Latest of This And More at [ThrowTheSwitch.org][]*
 
-*Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*
+[ThrowTheSwitch.org]: https://throwtheswitch.org

docs/UnityChangeLog.md

@@ -0,0 +1,110 @@
+# Unity Test - Change Log
+
+## A Note
+
+This document captures significant features and fixes to the Unity project core source files 
+and scripts. More detail can be found in the history on Github. 
+
+This project is now tracking changes in more detail. Previous releases get less detailed as
+we move back in histroy. 
+
+Prior to 2012, the project was hosted on SourceForge.net
+Prior to 2008, the project was an internal project and not released to the public.
+
+## Log
+
+### Unity 2.6.1 (Jan 2025)
+
+New Features:
+  
+  - Add `-n` comand line option as strict matcher again
+
+Significant Bugfixes:
+
+  - Protect against problems when mis-matched command line options selected
+
+Other:
+
+  - Protect against Conversion warnings in gcc
+  - Remove Redundant line-casts
+  - Make more internal functions static
+
+### Unity 2.6.0 (Mar 2024)
+
+New Features:
+
+  - Fill out missing variations of arrays, within, etc. 
+  - Add `TEST_PRINTF()`
+  - Add `TEST_MATRIX()` and `TEST_RANGE()` options and documentation
+  - Add support for searching `TEST_SOURCE_FILE()` for determining test dependencies
+  - Add Unity BDD plugin
+  - Add `UNITY_INCLUDE_EXEC_TIME` option to report test times
+  - Allow user to override test abort underlying mechanism
+  - Add `NOT_EQUAL*` and `NOT_WITHIN*` checks for floats and doubles 
+
+Significant Bugfixes:
+
+  - More portable validation of NaN and Infinity. Added `UNITY_IS_NAN` and `UNITY_IS_INF` options
+  - Add `UNITY_PROGMEM` configuration option
+  - Fix overflow detection of hex values when using arrays
+  - Fix scripts broken by Ruby standard changes
+
+Other:
+
+  - Avoid pointer comparison when one is null to avoid compiler warnings
+  - Significant improvements to documentation
+  - Updates to match latest Ruby style specification
+  - Meson, CMake, PlatformIO builds
+
+### Unity 2.5.2 (January 2021)
+
+  - improvements to RUN_TEST macro and generated RUN_TEST
+  - Fix `UNITY_TEST_ASSERT_BIT(S)_HIGH`
+  - Cleaner handling of details tracking by CMock
+
+### Unity 2.5.1 (May 2020)
+
+Mostly a bugfix and stability release.
+Bonus Features:
+
+  - Optional TEST_PRINTF macro
+  - Improve self-testing procedures.
+
+### Unity 2.5.0 (October 2019)
+
+It's been a LONG time since the last release of Unity. Finally, here it is!
+There are too many updates to list here, so some highlights:
+
+  - more standards compliant (without giving up on supporting ALL compilers, no matter how quirky)
+  - many more specialized assertions for better test feedback
+  - more examples for integrating into your world
+  - many many bugfixes and tweaks
+
+### Unity 2.4.3 (November 2017)
+
+  - Allow suiteSetUp() and suiteTearDown() to be povided as normal C functions
+  - Fix & Expand Greater Than / Less Than assertions for integers
+  - Built-in option to colorize test results
+  - Documentation updates
+
+### Unity 2.4.2 (September 2017)
+
+  - Fixed bug in UNTY_TEST_ASSERT_EACH_EQUAL_*
+  - Added TEST_ASSERT_GREATER_THAN and TEST_ASSERT_LESS_THAN
+  - Updated Module Generator to stop changing names when no style given
+  - Cleanup to custom float printing for accuracy
+  - Cleanup incorrect line numbers are partial name matching
+  - Reduce warnings from using popular function names as variable names
+
+### Unity 2.4.1 (April 2017)
+
+  - test runner generator can inject defines as well as headers
+  - added a built-in floating point print routine instead of relying on printf
+  - updated to new coding and naming standard
+  - updated documentation to be markdown instead of pdf
+  - fixed many many little bugs, most of which were supplied by the community (you people are awesome!)
+  - coding standard actually enforced in CI
+
+### Unity 2.4.0 (October, 2016)
+
+  - port from SourceForge and numerous bugfixes

docs/UnityConfigurationGuide.md

@@ -2,133 +2,118 @@
 
 ## C Standards, Compilers and Microcontrollers
 
-The embedded software world contains its challenges. Compilers support different
-revisions of the C Standard. They ignore requirements in places, sometimes to
-make the language more usable in some special regard. Sometimes it's to simplify
-their support. Sometimes it's due to specific quirks of the microcontroller they
-are targeting. Simulators add another dimension to this menagerie.
+The embedded software world contains its challenges.
+Compilers support different revisions of the C Standard.
+They ignore requirements in places, sometimes to make the language more usable in some special regard.
+Sometimes it's to simplify their support.
+Sometimes it's due to specific quirks of the microcontroller they are targeting.
+Simulators add another dimension to this menagerie.
 
-Unity is designed to run on almost anything that is targeted by a C compiler. It
-would be awesome if this could be done with zero configuration. While there are
-some targets that come close to this dream, it is sadly not universal. It is
-likely that you are going to need at least a couple of the configuration options
-described in this document.
-
-All of Unity's configuration options are `#defines`. Most of these are simple
-definitions. A couple are macros with arguments. They live inside the
-unity_internals.h header file. We don't necessarily recommend opening that file
-unless you really need to. That file is proof that a cross-platform library is
-challenging to build. From a more positive perspective, it is also proof that a
-great deal of complexity can be centralized primarily to one place to
-provide a more consistent and simple experience elsewhere.
+Unity is designed to run on almost anything that is targeted by a C compiler.
+It would be awesome if this could be done with zero configuration.
+While there are some targets that come close to this dream, it is sadly not universal.
+It is likely that you are going to need at least a couple of the configuration options described in this document.
 
+All of Unity's configuration options are `#defines`.
+Most of these are simple definitions.
+A couple are macros with arguments.
+They live inside the unity_internals.h header file.
+We don't necessarily recommend opening that file unless you really need to.
+That file is proof that a cross-platform library is challenging to build.
+From a more positive perspective, it is also proof that a great deal of complexity can be centralized primarily to one place to provide a more consistent and simple experience elsewhere.
 
 ### Using These Options
 
-It doesn't matter if you're using a target-specific compiler and a simulator or
-a native compiler. In either case, you've got a couple choices for configuring
-these options:
+It doesn't matter if you're using a target-specific compiler and a simulator or a native compiler.
+In either case, you've got a couple choices for configuring these options:
 
-1. Because these options are specified via C defines, you can pass most of these
-options to your compiler through command line compiler flags. Even if you're
-using an embedded target that forces you to use their overbearing IDE for all
-configuration, there will be a place somewhere in your project to configure
-defines for your compiler.
-2. You can create a custom `unity_config.h` configuration file (present in your
-toolchain's search paths). In this file, you will list definitions and macros
-specific to your target. All you must do is define `UNITY_INCLUDE_CONFIG_H` and
-Unity will rely on `unity_config.h` for any further definitions it may need.
+1. Because these options are specified via C defines, you can pass most of these options to your compiler through command line compiler flags. Even if you're using an embedded target that forces you to use their overbearing IDE for all configuration, there will be a place somewhere in your project to configure defines for your compiler.
+2. You can create a custom `unity_config.h` configuration file (present in your toolchain's search paths).
+  In this file, you will list definitions and macros specific to your target. All you must do is define `UNITY_INCLUDE_CONFIG_H` and Unity will rely on `unity_config.h` for any further definitions it may need.
 
-Unfortunately, it doesn't usually work well to just #define these things in the
-test itself. These defines need to take effect where ever unity.h is included.
-This would be test test, the test runner (if you're generating one), and from
-unity.c when it's compiled.
+Unfortunately, it doesn't usually work well to just #define these things in the test itself.
+These defines need to take effect where ever unity.h is included.
+This would be the test, the test runner (if you're generating one), and from unity.c when it's compiled.
 
 ## The Options
 
 ### Integer Types
 
-If you've been a C developer for long, you probably already know that C's
-concept of an integer varies from target to target. The C Standard has rules
-about the `int` matching the register size of the target microprocessor. It has
-rules about the `int` and how its size relates to other integer types. An `int`
-on one target might be 16 bits while on another target it might be 64. There are
-more specific types in compilers compliant with C99 or later, but that's
-certainly not every compiler you are likely to encounter. Therefore, Unity has a
-number of features for helping to adjust itself to match your required integer
-sizes. It starts off by trying to do it automatically.
+If you've been a C developer for long, you probably already know that C's concept of an integer varies from target to target.
+The C Standard has rules about the `int` matching the register size of the target microprocessor.
+It has rules about the `int` and how its size relates to other integer types.
+An `int` on one target might be 16 bits while on another target it might be 64.
+There are more specific types in compilers compliant with C99 or later, but that's certainly not every compiler you are likely to encounter.
+Therefore, Unity has a number of features for helping to adjust itself to match your required integer sizes.
+It starts off by trying to do it automatically.
 
-
-##### `UNITY_EXCLUDE_STDINT_H`
+#### `UNITY_EXCLUDE_STDINT_H`
 
 The first thing that Unity does to guess your types is check `stdint.h`.
-This file includes defines like `UINT_MAX` that Unity can use to
-learn a lot about your system. It's possible you don't want it to do this
-(um. why not?) or (more likely) it's possible that your system doesn't
-support `stdint.h`. If that's the case, you're going to want to define this.
-That way, Unity will know to skip the inclusion of this file and you won't
-be left with a compiler error.
+This file includes defines like `UINT_MAX` that Unity can use to learn a lot about your system.
+It's possible you don't want it to do this (um. why not?) or (more likely) it's possible that your system doesn't support `stdint.h`.
+If that's the case, you're going to want to define this.
+That way, Unity will know to skip the inclusion of this file and you won't be left with a compiler error.
 
 _Example:_
+
 ```C
 #define UNITY_EXCLUDE_STDINT_H
 ```
 
+#### `UNITY_EXCLUDE_LIMITS_H`
 
-##### `UNITY_EXCLUDE_LIMITS_H`
-
-The second attempt to guess your types is to check `limits.h`. Some compilers
-that don't support `stdint.h` could include `limits.h` instead. If you don't
-want Unity to check this file either, define this to make it skip the inclusion.
+The second attempt to guess your types is to check `limits.h`.
+Some compilers that don't support `stdint.h` could include `limits.h` instead.
+If you don't want Unity to check this file either, define this to make it skip the inclusion.
 
 _Example:_
+
 ```C
 #define UNITY_EXCLUDE_LIMITS_H
 ```
 
-If you've disabled both of the automatic options above, you're going to have to
-do the configuration yourself. Don't worry. Even this isn't too bad... there are
-just a handful of defines that you are going to specify if you don't like the
-defaults.
+If you've disabled both of the automatic options above, you're going to have to do the configuration yourself.
+Don't worry.
+Even this isn't too bad... there are just a handful of defines that you are going to specify if you don't like the defaults.
 
+#### `UNITY_INT_WIDTH`
 
-##### `UNITY_INT_WIDTH`
-
-Define this to be the number of bits an `int` takes up on your system. The
-default, if not autodetected, is 32 bits.
+Define this to be the number of bits an `int` takes up on your system.
+The default, if not autodetected, is 32 bits.
 
 _Example:_
+
 ```C
 #define UNITY_INT_WIDTH 16
 ```
 
+#### `UNITY_LONG_WIDTH`
 
-##### `UNITY_LONG_WIDTH`
-
-Define this to be the number of bits a `long` takes up on your system. The
-default, if not autodetected, is 32 bits. This is used to figure out what kind
-of 64-bit support your system can handle. Does it need to specify a `long` or a
-`long long` to get a 64-bit value. On 16-bit systems, this option is going to be
-ignored.
+Define this to be the number of bits a `long` takes up on your system.
+The default, if not autodetected, is 32 bits.
+This is used to figure out what kind of 64-bit support your system can handle.
+Does it need to specify a `long` or a `long long` to get a 64-bit value.
+On 16-bit systems, this option is going to be ignored.
 
 _Example:_
+
 ```C
 #define UNITY_LONG_WIDTH 16
 ```
 
+#### `UNITY_POINTER_WIDTH`
 
-##### `UNITY_POINTER_WIDTH`
+Define this to be the number of bits a pointer takes up on your system.
+The default, if not autodetected, is 32-bits.
+If you're getting ugly compiler warnings about casting from pointers, this is the one to look at.
 
-Define this to be the number of bits a pointer takes up on your system. The
-default, if not autodetected, is 32-bits. If you're getting ugly compiler
-warnings about casting from pointers, this is the one to look at.
-
-_Hint:_ In order to support exotic processors (for example TI C55x with a pointer
-width of 23-bit), choose the next power of two (in this case 32-bit).
+_Hint:_ In order to support exotic processors (for example TI C55x with a pointer width of 23-bit), choose the next power of two (in this case 32-bit).
 
 _Supported values:_ 16, 32 and 64
 
 _Example:_
+
 ```C
 // Choose on of these #defines to set your pointer width (if not autodetected)
 //#define UNITY_POINTER_WIDTH 16
@@ -136,140 +121,137 @@ _Example:_
 #define UNITY_POINTER_WIDTH 64 // Set UNITY_POINTER_WIDTH to 64-bit
 ```
 
+#### `UNITY_COMPARE_PTRS_ON_ZERO_ARRAY`
 
-##### `UNITY_SUPPORT_64`
+Define this to make all array assertions compare pointers instead of contents when a length of zero is specified. When not enabled,
+defining a length of zero will always result in a failure and a message warning the user that they have tried to compare empty
+arrays.
 
-Unity will automatically include 64-bit support if it auto-detects it, or if
-your `int`, `long`, or pointer widths are greater than 32-bits. Define this to
-enable 64-bit support if none of the other options already did it for you. There
-can be a significant size and speed impact to enabling 64-bit support on small
-targets, so don't define it if you don't need it.
+#### `UNITY_SUPPORT_64`
+
+Unity will automatically include 64-bit support if it auto-detects it, or if your `int`, `long`, or pointer widths are greater than 32-bits.
+Define this to enable 64-bit support if none of the other options already did it for you.
+There can be a significant size and speed impact to enabling 64-bit support on small targets, so don't define it if you don't need it.
 
 _Example:_
+
 ```C
 #define UNITY_SUPPORT_64
 ```
 
-
 ### Floating Point Types
 
-In the embedded world, it's not uncommon for targets to have no support for
-floating point operations at all or to have support that is limited to only
-single precision. We are able to guess integer sizes on the fly because integers
-are always available in at least one size. Floating point, on the other hand, is
-sometimes not available at all. Trying to include `float.h` on these platforms
-would result in an error. This leaves manual configuration as the only option.
+In the embedded world, it's not uncommon for targets to have no support for floating point operations at all or to have support that is limited to only single precision.
+We are able to guess integer sizes on the fly because integers are always available in at least one size.
+Floating point, on the other hand, is sometimes not available at all.
+Trying to include `float.h` on these platforms would result in an error. This leaves manual configuration as the only option.
 
+#### `UNITY_INCLUDE_FLOAT`
 
-##### `UNITY_INCLUDE_FLOAT`
+#### `UNITY_EXCLUDE_FLOAT`
 
-##### `UNITY_EXCLUDE_FLOAT`
+#### `UNITY_INCLUDE_DOUBLE`
 
-##### `UNITY_INCLUDE_DOUBLE`
+#### `UNITY_EXCLUDE_DOUBLE`
 
-##### `UNITY_EXCLUDE_DOUBLE`
-
-By default, Unity guesses that you will want single precision floating point
-support, but not double precision. It's easy to change either of these using the
-include and exclude options here. You may include neither, either, or both, as
-suits your needs. For features that are enabled, the following floating point
-options also become available.
+By default, Unity guesses that you will want single precision floating point support, but not double precision.
+It's easy to change either of these using the include and exclude options here.
+You may include neither, either, or both, as suits your needs.
+For features that are enabled, the following floating point options also become available.
 
 _Example:_
+
 ```C
 //what manner of strange processor is this?
 #define UNITY_EXCLUDE_FLOAT
 #define UNITY_INCLUDE_DOUBLE
 ```
 
+#### `UNITY_EXCLUDE_FLOAT_PRINT`
 
-##### `UNITY_EXCLUDE_FLOAT_PRINT`
-
-Unity aims for as small of a footprint as possible and avoids most standard
-library calls (some embedded platforms don’t have a standard library!). Because
-of this, its routines for printing integer values are minimalist and hand-coded.
+Unity aims for as small of a footprint as possible and avoids most standard library calls (some embedded platforms don’t have a standard library!).
+Because of this, its routines for printing integer values are minimalist and hand-coded.
 Therefore, the display of floating point values during a failure are optional.
-By default, Unity will print the actual results of floating point assertion
-failure (e.g. ”Expected 4.56 Was 4.68”). To not include this extra support, you
-can use this define to instead respond to a failed assertion with a message like
-”Values Not Within Delta”. If you would like verbose failure messages for floating
-point assertions, use these options to give more explicit failure messages.
+By default, Unity will print the actual results of floating point assertion failure (e.g. ”Expected 4.56 Was 4.68”).
+To not include this extra support, you can use this define to instead respond to a failed assertion with a message like ”Values Not Within Delta”.
+If you would like verbose failure messages for floating point assertions, use these options to give more explicit failure messages.
 
 _Example:_
+
 ```C
 #define UNITY_EXCLUDE_FLOAT_PRINT
 ```
 
+#### `UNITY_FLOAT_TYPE`
 
-##### `UNITY_FLOAT_TYPE`
-
-If enabled, Unity assumes you want your `FLOAT` asserts to compare standard C
-floats. If your compiler supports a specialty floating point type, you can
-always override this behavior by using this definition.
+If enabled, Unity assumes you want your `FLOAT` asserts to compare standard C floats.
+If your compiler supports a specialty floating point type, you can always override this behavior by using this definition.
 
 _Example:_
+
 ```C
 #define UNITY_FLOAT_TYPE float16_t
 ```
 
+#### `UNITY_DOUBLE_TYPE`
 
-##### `UNITY_DOUBLE_TYPE`
-
-If enabled, Unity assumes you want your `DOUBLE` asserts to compare standard C
-doubles. If you would like to change this, you can specify something else by
-using this option. For example, defining `UNITY_DOUBLE_TYPE` to `long double`
-could enable gargantuan floating point types on your 64-bit processor instead of
-the standard `double`.
+If enabled, Unity assumes you want your `DOUBLE` asserts to compare standard C doubles.
+If you would like to change this, you can specify something else by using this option.
+For example, defining `UNITY_DOUBLE_TYPE` to `long double` could enable gargantuan floating point types on your 64-bit processor instead of the standard `double`.
 
 _Example:_
+
 ```C
 #define UNITY_DOUBLE_TYPE long double
 ```
 
+#### `UNITY_FLOAT_PRECISION`
 
-##### `UNITY_FLOAT_PRECISION`
+#### `UNITY_DOUBLE_PRECISION`
 
-##### `UNITY_DOUBLE_PRECISION`
-
-If you look up `UNITY_ASSERT_EQUAL_FLOAT` and `UNITY_ASSERT_EQUAL_DOUBLE` as
-documented in the big daddy Unity Assertion Guide, you will learn that they are
-not really asserting that two values are equal but rather that two values are
-"close enough" to equal. "Close enough" is controlled by these precision
-configuration options. If you are working with 32-bit floats and/or 64-bit
-doubles (the normal on most processors), you should have no need to change these
-options. They are both set to give you approximately 1 significant bit in either
-direction. The float precision is 0.00001 while the double is 10-12.
-For further details on how this works, see the appendix of the Unity Assertion
-Guide.
+If you look up `UNITY_ASSERT_EQUAL_FLOAT` and `UNITY_ASSERT_EQUAL_DOUBLE` as documented in the big daddy Unity Assertion Guide, you will learn that they are not really asserting that two values are equal but rather that two values are "close enough" to equal.
+"Close enough" is controlled by these precision configuration options.
+If you are working with 32-bit floats and/or 64-bit doubles (the normal on most processors), you should have no need to change these options.
+They are both set to give you approximately 1 significant bit in either direction.
+The float precision is 0.00001 while the double is 10-12.
+For further details on how this works, see the appendix of the Unity Assertion Guide.
 
 _Example:_
+
 ```C
 #define UNITY_FLOAT_PRECISION 0.001f
 ```
 
+#### `UNITY_IS_NAN` and `UNITY_IS_INF`
+
+If your toolchain defines `isnan` and `isinf` in `math.h` as macros, nothing needs to be done. If your toolchain doesn't define these, Unity
+will create these macros itself. You may override either or both of these defines to specify how you want to evaluate if a number is NaN or Infinity.
+
+_Example:_
+
+```C
+#define UNITY_IS_NAN(n) ((n != n) ? 1 : 0)
+```
 
 ### Miscellaneous
 
-##### `UNITY_EXCLUDE_STDDEF_H`
+#### `UNITY_EXCLUDE_STDDEF_H`
 
-Unity uses the `NULL` macro, which defines the value of a null pointer constant,
-defined in `stddef.h` by default. If you want to provide
-your own macro for this, you should exclude the `stddef.h` header file by adding this
-define to your configuration.
+Unity uses the `NULL` macro, which defines the value of a null pointer constant, defined in `stddef.h` by default.
+If you want to provide your own macro for this, you should exclude the `stddef.h` header file by adding this define to your configuration.
 
 _Example:_
+
 ```C
 #define UNITY_EXCLUDE_STDDEF_H
 ```
 
-
 #### `UNITY_INCLUDE_PRINT_FORMATTED`
 
-Unity provides a simple (and very basic) printf-like string output implementation,
-which is able to print a string modified by the following format string modifiers:
+Unity provides a simple (and very basic) printf-like string output implementation, which is able to print a string modified by the following format string modifiers:
 
 - __%d__ - signed value (decimal)
-- __%i__ - same as __%i__
+- __%i__ - same as __%d__
 - __%u__ - unsigned value (decimal)
 - __%f__ - float/Double (if float support is activated)
 - __%g__ - same as __%f__
@@ -281,7 +263,17 @@ which is able to print a string modified by the following format string modifier
 - __%s__ - a string (e.g. "string")
 - __%%__ - The "%" symbol (escaped)
 
+Length specifiers are also supported. If you are using long long types, make sure UNITY_SUPPORT_64 is true to ensure they are printed correctly.
+
+- __%ld__ - signed long value (decimal)
+- __%lld__ - signed long long value (decimal)
+- __%lu__ - unsigned long value (decimal)
+- __%llu__ - unsigned long long value (decimal)
+- __%lx__ - unsigned long value (hexadecimal)
+- __%llx__ - unsigned long long value (hexadecimal)
+
 _Example:_
+
 ```C
 #define UNITY_INCLUDE_PRINT_FORMATTED
 
@@ -295,44 +287,38 @@ TEST_PRINTF("Pointer   %p\n", &a);
 TEST_PRINTF("Character %c\n", 'F');
 TEST_PRINTF("String    %s\n", "My string");
 TEST_PRINTF("Percent   %%\n");
-TEST_PRINTF("Color Red \033[41mFAIL\033[00m\n");
+TEST_PRINTF("Unsigned long long %llu\n", 922337203685477580);
+TEST_PRINTF("Color Red \033[41mFAIL\033[0m\n");
 TEST_PRINTF("\n");
 TEST_PRINTF("Multiple (%d) (%i) (%u) (%x)\n", -100, 0, 200, 0x12345);
 ```
 
-
 ### Toolset Customization
 
-In addition to the options listed above, there are a number of other options
-which will come in handy to customize Unity's behavior for your specific
-toolchain. It is possible that you may not need to touch any of these... but
-certain platforms, particularly those running in simulators, may need to jump
-through extra hoops to run properly. These macros will help in those
-situations.
+In addition to the options listed above, there are a number of other options which will come in handy to customize Unity's behavior for your specific toolchain.
+It is possible that you may not need to touch any of these... but certain platforms, particularly those running in simulators, may need to jump through extra hoops to run properly.
+These macros will help in those situations.
 
+#### `UNITY_OUTPUT_CHAR(a)`
 
-##### `UNITY_OUTPUT_CHAR(a)`
+#### `UNITY_OUTPUT_FLUSH()`
 
-##### `UNITY_OUTPUT_FLUSH()`
+#### `UNITY_OUTPUT_START()`
 
-##### `UNITY_OUTPUT_START()`
+#### `UNITY_OUTPUT_COMPLETE()`
 
-##### `UNITY_OUTPUT_COMPLETE()`
-
-By default, Unity prints its results to `stdout` as it runs. This works
-perfectly fine in most situations where you are using a native compiler for
-testing. It works on some simulators as well so long as they have `stdout`
-routed back to the command line. There are times, however, where the simulator
-will lack support for dumping results or you will want to route results
-elsewhere for other reasons. In these cases, you should define the
-`UNITY_OUTPUT_CHAR` macro. This macro accepts a single character at a time (as
-an `int`, since this is the parameter type of the standard C `putchar` function
-most commonly used). You may replace this with whatever function call you like.
+By default, Unity prints its results to `stdout` as it runs.
+This works perfectly fine in most situations where you are using a native compiler for testing.
+It works on some simulators as well so long as they have `stdout` routed back to the command line.
+There are times, however, where the simulator will lack support for dumping results or you will want to route results elsewhere for other reasons.
+In these cases, you should define the `UNITY_OUTPUT_CHAR` macro.
+This macro accepts a single character at a time (as an `int`, since this is the parameter type of the standard C `putchar` function most commonly used).
+You may replace this with whatever function call you like.
 
 _Example:_
-Say you are forced to run your test suite on an embedded processor with no
-`stdout` option. You decide to route your test result output to a custom serial
-`RS232_putc()` function you wrote like thus:
+Say you are forced to run your test suite on an embedded processor with no `stdout` option.
+You decide to route your test result output to a custom serial `RS232_putc()` function you wrote like thus:
+
 ```C
 #include "RS232_header.h"
 ...
@@ -343,67 +329,63 @@ Say you are forced to run your test suite on an embedded processor with no
 ```
 
 _Note:_
-`UNITY_OUTPUT_FLUSH()` can be set to the standard out flush function simply by
-specifying `UNITY_USE_FLUSH_STDOUT`. No other defines are required.
+`UNITY_OUTPUT_FLUSH()` can be set to the standard out flush function simply by specifying `UNITY_USE_FLUSH_STDOUT`.
+No other defines are required.
 
+#### `UNITY_OUTPUT_FOR_ECLIPSE`
 
-##### `UNITY_OUTPUT_FOR_ECLIPSE`
+#### `UNITY_OUTPUT_FOR_IAR_WORKBENCH`
 
-##### `UNITY_OUTPUT_FOR_IAR_WORKBENCH`
+#### `UNITY_OUTPUT_FOR_QT_CREATOR`
 
-##### `UNITY_OUTPUT_FOR_QT_CREATOR`
+When managing your own builds, it is often handy to have messages output in a format which is recognized by your IDE.
+These are some standard formats which can be supported.
+If you're using Ceedling to manage your builds, it is better to stick with the standard format (leaving these all undefined) and allow Ceedling to use its own decorators.
 
-When managing your own builds, it is often handy to have messages output in a format which is
-recognized by your IDE. These are some standard formats which can be supported. If you're using
-Ceedling to manage your builds, it is better to stick with the standard format (leaving these
-all undefined) and allow Ceedling to use its own decorators.
+#### `UNITY_PTR_ATTRIBUTE`
 
-
-##### `UNITY_PTR_ATTRIBUTE`
-
-Some compilers require a custom attribute to be assigned to pointers, like
-`near` or `far`. In these cases, you can give Unity a safe default for these by
-defining this option with the attribute you would like.
+Some compilers require a custom attribute to be assigned to pointers, like `near` or `far`.
+In these cases, you can give Unity a safe default for these by defining this option with the attribute you would like.
 
 _Example:_
+
 ```C
 #define UNITY_PTR_ATTRIBUTE __attribute__((far))
 #define UNITY_PTR_ATTRIBUTE near
 ```
 
-##### `UNITY_PRINT_EOL`
+#### `UNITY_PRINT_EOL`
 
-By default, Unity outputs \n at the end of each line of output. This is easy
-to parse by the scripts, by Ceedling, etc, but it might not be ideal for YOUR
-system. Feel free to override this and to make it whatever you wish.
+By default, Unity outputs \n at the end of each line of output.
+This is easy to parse by the scripts, by Ceedling, etc, but it might not be ideal for YOUR system.
+Feel free to override this and to make it whatever you wish.
 
 _Example:_
+
 ```C
-#define UNITY_PRINT_EOL { UNITY_OUTPUT_CHAR('\r'); UNITY_OUTPUT_CHAR('\n') }
+#define UNITY_PRINT_EOL { UNITY_OUTPUT_CHAR('\r'); UNITY_OUTPUT_CHAR('\n'); }
 ```
 
+#### `UNITY_EXCLUDE_DETAILS`
 
-##### `UNITY_EXCLUDE_DETAILS`
-
-This is an option for if you absolutely must squeeze every byte of memory out of
-your system. Unity stores a set of internal scratchpads which are used to pass
-extra detail information around. It's used by systems like CMock in order to
-report which function or argument flagged an error. If you're not using CMock and
-you're not using these details for other things, then you can exclude them.
+This is an option for if you absolutely must squeeze every byte of memory out of your system.
+Unity stores a set of internal scratchpads which are used to pass extra detail information around.
+It's used by systems like CMock in order to report which function or argument flagged an error.
+If you're not using CMock and you're not using these details for other things, then you can exclude them.
 
 _Example:_
+
 ```C
 #define UNITY_EXCLUDE_DETAILS
 ```
 
-##### `UNITY_PRINT_TEST_CONTEXT`
+#### `UNITY_PRINT_TEST_CONTEXT`
 
-This option allows you to specify your own function to print additional context
-as part of the error message when a test has failed. It can be useful if you
-want to output some specific information about the state of the test at the point
-of failure, and `UNITY_SET_DETAILS` isn't flexible enough for your needs.
+This option allows you to specify your own function to print additional context as part of the error message when a test has failed.
+It can be useful if you want to output some specific information about the state of the test at the point of failure, and `UNITY_SET_DETAILS` isn't flexible enough for your needs.
 
 _Example:_
+
 ```C
 #define UNITY_PRINT_TEST_CONTEXT PrintIterationCount
 
@@ -415,82 +397,196 @@ void PrintIterationCount(void)
 }
 ```
 
-##### `UNITY_EXCLUDE_SETJMP`
+#### `UNITY_EXCLUDE_SETJMP`
 
-If your embedded system doesn't support the standard library setjmp, you can
-exclude Unity's reliance on this by using this define. This dropped dependence
-comes at a price, though. You will be unable to use custom helper functions for
-your tests, and you will be unable to use tools like CMock. Very likely, if your
-compiler doesn't support setjmp, you wouldn't have had the memory space for those
-things anyway, though... so this option exists for those situations.
+If your embedded system doesn't support the standard library setjmp, you can exclude Unity's reliance on this by using this define.
+This dropped dependence comes at a price, though.
+You will be unable to use custom helper functions for your tests, and you will be unable to use tools like CMock.
+Very likely, if your compiler doesn't support setjmp, you wouldn't have had the memory space for those things anyway, though... so this option exists for those situations.
 
 _Example:_
+
 ```C
 #define UNITY_EXCLUDE_SETJMP
 ```
 
-##### `UNITY_OUTPUT_COLOR`
+#### `UNITY_TEST_PROTECT`
+
+#### `UNITY_TEST_ABORT`
+
+Unity handles test failures via `setjmp`/`longjmp` pair by default. As mentioned above, you can disable this with `UNITY_EXCLUDE_SETJMP`. You can also customise what happens on every `TEST_PROTECT` and `TEST_ABORT` call. This can be accomplished by providing user-defined `UNITY_TEST_PROTECT` and `UNITY_TEST_ABORT` macros (and these may be defined independently).
+
+`UNITY_TEST_PROTECT` is used as an `if` statement expression, and has to evaluate to `true` on the first call (when saving stack environment with `setjmp`), and to `false` when it returns as a result of a `TEST_ABORT` (when restoring the stack environment with `longjmp`).
+
+Whenever an assert macro fails, `TEST_ABORT` is used to restore the stack environment previously set by `TEST_PROTECT`. This part may be overriden with `UNITY_TEST_ABORT`, e.g. if custom failure handling is needed.
+
+_Example 1:_
+
+Calling `longjmp` on your target is possible, but has a platform-specific (or implementation-specific) set of prerequisites, e.g. privileged access level. You can extend the default behaviour of `TEST_PROTECT` and `TEST_ABORT` as:
+
+`unity_config.h`:
+
+```C
+#include "my_custom_test_handlers.h"
+
+#define UNITY_TEST_PROTECT() custom_test_protect()
+#define UNITY_TEST_ABORT()   custom_test_abort()
+```
+
+`my_custom_test_handlers.c`:
+
+```C
+int custom_test_protect(void) {
+  platform_specific_code();
+  return setjmp(Unity.AbortFrame) == 0;
+}
+
+UNITY_NORETURN void custom_test_abort(void) {
+  more_platform_specific_code();
+  longjmp(Unity.AbortFrame, 1);
+}
+```
+
+_Example 2:_
+
+Unity is used to provide the assertion macros only, and an external test harness/runner is used for test orchestration/reporting. In this case you can easily plug your code by overriding `TEST_ABORT` as:
+
+`unity_config.h`:
+
+```C
+#include "my_custom_test_handlers.h"
+
+#define UNITY_TEST_PROTECT() 1
+#define UNITY_TEST_ABORT()   custom_test_abort()
+```
+
+`my_custom_test_handlers.c`:
+
+```C
+void custom_test_abort(void) {
+  if (Unity.CurrentTestFailed == 1) {
+    custom_failed_test_handler();
+  } else if (Unity.CurrentTestIgnored == 1) {
+    custom_ignored_test_handler();
+  }
+}
+```
+
+#### `UNITY_OUTPUT_COLOR`
 
 If you want to add color using ANSI escape codes you can use this define.
 
 _Example:_
+
 ```C
 #define UNITY_OUTPUT_COLOR
 ```
 
-##### `UNITY_SHORTHAND_AS_INT`
-##### `UNITY_SHORTHAND_AS_MEM`
-##### `UNITY_SHORTHAND_AS_RAW`
-##### `UNITY_SHORTHAND_AS_NONE`
+#### `UNITY_INCLUDE_EXEC_TIME`
 
-These options  give you control of the `TEST_ASSERT_EQUAL` and the
-`TEST_ASSERT_NOT_EQUAL` shorthand assertions. Historically, Unity treated the
-former as an alias for an integer comparison. It treated the latter as a direct
-comparison using `!=`. This assymetry was confusing, but there was much
-disagreement as to how best to treat this pair of assertions. These four options
-will allow you to specify how Unity will treat these assertions.
+Define this to measure and report execution time for each test in the suite. When enabled, Unity will do
+it's best to automatically find a way to determine the time in milliseconds. On most Windows, macos, or 
+Linux environments, this is automatic. If not, you can give Unity more information.
 
-  - AS INT - the values will be cast to integers and directly compared. Arguments
-             that don't cast easily to integers will cause compiler errors.
-  - AS MEM - the address of both values will be taken and the entire object's
-             memory footprint will be compared byte by byte. Directly placing
-             constant numbers like `456` as expected values will cause errors.
-  - AS_RAW - Unity assumes that you can compare the two values using `==` and `!=`
-             and will do so. No details are given about mismatches, because it
-             doesn't really know what type it's dealing with.
-  - AS_NONE - Unity will disallow the use of these shorthand macros altogether,
-             insisting that developers choose a more descriptive option.
+#### `UNITY_CLOCK_MS`
+
+If you're working on a system (embedded or otherwise) which has an accessible millisecond timer. You can
+define `UNITY_CLOCK_MS` to be the name of the function which returns the millisecond timer. It will then
+attempt to use that function for timing purposes.
+
+#### `UNITY_EXEC_TIME_START`
+
+Define this hook to start a millisecond timer if necessary.
+
+#### `UNITY_EXEC_TIME_STOP`
+
+Define this hook to stop a millisecond timer if necessary.
+
+#### `UNITY_PRINT_EXEC_TIME`
+
+Define this hook to print the current execution time. Used to report the milliseconds elapsed.
+
+#### `UNITY_TIME_TYPE`
+
+Finally, this can be set to the type which holds the millisecond timer.
+
+#### `UNITY_SHORTHAND_AS_INT`
+
+#### `UNITY_SHORTHAND_AS_MEM`
+
+#### `UNITY_SHORTHAND_AS_RAW`
+
+#### `UNITY_SHORTHAND_AS_NONE`
+
+These options give you control of the `TEST_ASSERT_EQUAL` and the `TEST_ASSERT_NOT_EQUAL` shorthand assertions.
+Historically, Unity treated the former as an alias for an integer comparison.
+It treated the latter as a direct comparison using `!=`.
+This asymmetry was confusing, but there was much disagreement as to how best to treat this pair of assertions.
+These four options will allow you to specify how Unity will treat these assertions.
+
+- AS INT - the values will be cast to integers and directly compared.
+  Arguments that don't cast easily to integers will cause compiler errors.
+- AS MEM - the address of both values will be taken and the entire object's memory footprint will be compared byte by byte.
+  Directly placing constant numbers like `456` as expected values will cause errors.
+- AS_RAW - Unity assumes that you can compare the two values using `==` and `!=` and will do so.
+  No details are given about mismatches, because it doesn't really know what type it's dealing with.
+- AS_NONE - Unity will disallow the use of these shorthand macros altogether, insisting that developers choose a more descriptive option.
 
 #### `UNITY_SUPPORT_VARIADIC_MACROS`
 
-This will force Unity to support variadic macros when using its own built-in
-RUN_TEST macro. This will rarely be necessary. Most often, Unity will automatically
-detect if the compiler supports variadic macros by checking to see if it's C99+
-compatible. In the event that the compiler supports variadic macros, but is primarily
-C89 (ANSI), defining this option will allow you to use them. This option is also not
-necessary when using Ceedling or the test runner generator script.
+This will force Unity to support variadic macros when using its own built-in RUN_TEST macro.
+This will rarely be necessary. Most often, Unity will automatically detect if the compiler supports variadic macros by checking to see if it's C99+ compatible.
+In the event that the compiler supports variadic macros, but is primarily C89 (ANSI), defining this option will allow you to use them.
+This option is also not necessary when using Ceedling or the test runner generator script.
+
+#### `UNITY_SUPPORT_TEST_CASES`
+
+Unity can automatically define all supported parameterized tests macros.
+That feature is disabled by default.
+To enable it, use the following example:
+
+```C
+#define UNITY_SUPPORT_TEST_CASES
+```
+
+You can manually provide required `TEST_CASE`, `TEST_RANGE` or `TEST_MATRIX` macro definitions
+before including `unity.h`, and they won't be redefined.
+If you provide one of the following macros, some of default definitions will not be
+defined:
+| User defines macro | Unity will _not_ define following macro |
+|---|---|
+| `UNITY_EXCLUDE_TEST_CASE` | `TEST_CASE` |
+| `UNITY_EXCLUDE_TEST_RANGE` | `TEST_RANGE` |
+| `UNITY_EXCLUDE_TEST_MATRIX` | `TEST_MATRIX` |
+| `TEST_CASE` | `TEST_CASE` |
+| `TEST_RANGE` | `TEST_RANGE` |
+| `TEST_MATRIX` | `TEST_MATRIX` |
+
+`UNITY_EXCLUDE_TEST_*` defines is not processed by test runner generator script.
+If you exclude one of them from definition, you should provide your own definition
+for them or avoid using undefined `TEST_*` macro as a test generator.
+Otherwise, compiler cannot build source code file with provided call.
+
+_Note:_
+That feature requires variadic macro support by compiler. If required feature
+is not detected, it will not be enabled, even though preprocessor macro is defined.
 
 ## Getting Into The Guts
 
-There will be cases where the options above aren't quite going to get everything
-perfect. They are likely sufficient for any situation where you are compiling
-and executing your tests with a native toolchain (e.g. clang on Mac). These
-options may even get you through the majority of cases encountered in working
-with a target simulator run from your local command line. But especially if you
-must run your test suite on your target hardware, your Unity configuration will
-require special help. This special help will usually reside in one of two
-places: the `main()` function or the `RUN_TEST` macro. Let's look at how these
-work.
+There will be cases where the options above aren't quite going to get everything perfect.
+They are likely sufficient for any situation where you are compiling and executing your tests with a native toolchain (e.g. clang on Mac).
+These options may even get you through the majority of cases encountered in working with a target simulator run from your local command line.
+But especially if you must run your test suite on your target hardware, your Unity configuration will
+require special help.
+This special help will usually reside in one of two places: the `main()` function or the `RUN_TEST` macro.
+Let's look at how these work.
 
+### `main()`
 
-##### `main()`
-
-Each test module is compiled and run on its own, separate from the other test
-files in your project. Each test file, therefore, has a `main` function. This
-`main` function will need to contain whatever code is necessary to initialize
-your system to a workable state. This is particularly true for situations where
-you must set up a memory map or initialize a communication channel for the
-output of your test results.
+Each test module is compiled and run on its own, separate from the other test files in your project.
+Each test file, therefore, has a `main` function.
+This `main` function will need to contain whatever code is necessary to initialize your system to a workable state.
+This is particularly true for situations where you must set up a memory map or initialize a communication channel for the output of your test results.
 
 A simple main function looks something like this:
 
@@ -504,26 +600,22 @@ int main(void) {
 }
 ```
 
-You can see that our main function doesn't bother taking any arguments. For our
-most barebones case, we'll never have arguments because we just run all the
-tests each time. Instead, we start by calling `UNITY_BEGIN`. We run each test
-(in whatever order we wish). Finally, we call `UNITY_END`, returning its return
-value (which is the total number of failures).
+You can see that our main function doesn't bother taking any arguments.
+For our most barebones case, we'll never have arguments because we just run all the tests each time.
+Instead, we start by calling `UNITY_BEGIN`.
+We run each test (in whatever order we wish).
+Finally, we call `UNITY_END`, returning its return value (which is the total number of failures).
 
-It should be easy to see that you can add code before any test cases are run or
-after all the test cases have completed. This allows you to do any needed
-system-wide setup or teardown that might be required for your special
-circumstances.
+It should be easy to see that you can add code before any test cases are run or after all the test cases have completed.
+This allows you to do any needed system-wide setup or teardown that might be required for your special circumstances.
 
+#### `RUN_TEST`
 
-##### `RUN_TEST`
-
-The `RUN_TEST` macro is called with each test case function. Its job is to
-perform whatever setup and teardown is necessary for executing a single test
-case function. This includes catching failures, calling the test module's
-`setUp()` and `tearDown()` functions, and calling `UnityConcludeTest()`. If
-using CMock or test coverage, there will be additional stubs in use here. A
-simple minimalist RUN_TEST macro looks something like this:
+The `RUN_TEST` macro is called with each test case function.
+Its job is to perform whatever setup and teardown is necessary for executing a single test case function.
+This includes catching failures, calling the test module's `setUp()` and `tearDown()` functions, and calling `UnityConcludeTest()`.
+If using CMock or test coverage, there will be additional stubs in use here.
+A simple minimalist RUN_TEST macro looks something like this:
 
 ```C
 #define RUN_TEST(testfunc) \
@@ -537,27 +629,26 @@ simple minimalist RUN_TEST macro looks something like this:
     UnityConcludeTest();
 ```
 
-So that's quite a macro, huh? It gives you a glimpse of what kind of stuff Unity
-has to deal with for every single test case. For each test case, we declare that
-it is a new test. Then we run `setUp` and our test function. These are run
-within a `TEST_PROTECT` block, the function of which is to handle failures that
-occur during the test. Then, assuming our test is still running and hasn't been
-ignored, we run `tearDown`. No matter what, our last step is to conclude this
-test before moving on to the next.
-
-Let's say you need to add a call to `fsync` to force all of your output data to
-flush to a file after each test. You could easily insert this after your
-`UnityConcludeTest` call. Maybe you want to write an xml tag before and after
-each result set. Again, you could do this by adding lines to this macro. Updates
-to this macro are for the occasions when you need an action before or after
-every single test case throughout your entire suite of tests.
+So that's quite a macro, huh?
+It gives you a glimpse of what kind of stuff Unity has to deal with for every single test case.
+For each test case, we declare that it is a new test.
+Then we run `setUp` and our test function.
+These are run within a `TEST_PROTECT` block, the function of which is to handle failures that occur during the test.
+Then, assuming our test is still running and hasn't been ignored, we run `tearDown`.
+No matter what, our last step is to conclude this test before moving on to the next.
 
+Let's say you need to add a call to `fsync` to force all of your output data to flush to a file after each test.
+You could easily insert this after your `UnityConcludeTest` call.
+Maybe you want to write an xml tag before and after each result set.
+Again, you could do this by adding lines to this macro.
+Updates to this macro are for the occasions when you need an action before or after every single test case throughout your entire suite of tests.
 
 ## Happy Porting
 
-The defines and macros in this guide should help you port Unity to just about
-any C target we can imagine. If you run into a snag or two, don't be afraid of
-asking for help on the forums. We love a good challenge!
+The defines and macros in this guide should help you port Unity to just about any C target we can imagine.
+If you run into a snag or two, don't be afraid of asking for help on the forums.
+We love a good challenge!
 
+*Find The Latest of This And More at [ThrowTheSwitch.org][]*
 
-*Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*
+[ThrowTheSwitch.org]: https://throwtheswitch.org

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.
+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.
+- `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.
-
+- `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.
+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.
+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

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,81 +93,75 @@ 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 this:
 
 ```Ruby
 gen = UnityTestRunnerGenerator.new(options)
 test_files.each do |f|
-  gen.run(f, File.basename(f,'.c')+"Runner.c"
+  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.
+#### 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.
 
+##### `:defines`
+
+This option specifies an array of definitions to be `#define`'d at the top of your runner C file.
+Each definition will be wrapped in an `#ifndef`.
 
 ##### `: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.
 
+This option can also be specified at the command prompt as `--suite_setup=""`
 
 ##### `: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`.
+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.
+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.
 
+This option can also be specified at the command prompt as `--suite_teardown=""`
 
 ##### `: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.
+
+This option can also be specified at the command prompt as `--externc`
 
 ##### `: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 +174,340 @@ 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.
+
+This option can also be specified at the command prompt as `--cexception`
 
 ##### `: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)'`.
 
+##### `:use_param_tests`
+
+This option enables parameterized test usage.
+That tests accepts arguments from `TEST_CASE` and `TEST_RANGE` macros,
+that are located above current test definition.
+By default, Unity assumes, that parameterized tests are disabled.
+
+Few usage examples can be found in `/test/tests/test_unity_parameterized.c` file.
+
+You should define `UNITY_SUPPORT_TEST_CASES` macro for tests success compiling,
+if you enable current option.
+
+You can see a list of supported macros in the
+[Parameterized tests provided macros](#parameterized-tests-provided-macros)
+section that follows.
+
+This option can also be specified at the command prompt as `--use_param_tests=1`
+
+##### `:cmdline_args`
+
+When set to `true`, the generated test runner can accept a number of
+options to modify how the test(s) are run.
+
+Ensure Unity is compiled with `UNITY_USE_COMMAND_LINE_ARGS` defined or else
+the required functions will not exist.
+
+These are the available options:
+
+| Option    | Description                                       |
+| --------- | ------------------------------------------------- |
+| `-l`      | List all tests and exit                           |
+| `-f NAME` | Filter to run only tests whose name includes NAME |
+| `-n NAME` | Run only the test named NAME                      |
+| `-h`      | show the Help menu that lists these options       |
+| `-q`      | Quiet/decrease verbosity                          |
+| `-v`      | increase Verbosity                                |
+| `-x NAME` | eXclude tests whose name includes NAME            |
+
+##### `:setup_name`
+
+Override the default test `setUp` function name.
+
+This option can also be specified at the command prompt as `--setup_name=""`
+
+##### `:teardown_name`
+
+Override the default test `tearDown` function name.
+
+This option can also be specified at the command prompt as `--teardown_name=""`
+
+##### `:test_reset_name`
+
+Override the default test `resetTest` function name.
+
+This option can also be specified at the command prompt as `--test_reset_name=""`
+
+##### `:test_verify_name`
+
+Override the default test `verifyTest` function name.
+
+This option can also be specified at the command prompt as `--test_verify_name=""`
+
+##### `:main_name`
+
+Override the test's `main()` function name (from `main` to whatever is specified).
+The sentinel value `:auto` will use the test's filename with the `.c` extension removed prefixed
+with `main_` as the "main" function.
+
+To clarify, if `:main_name == :auto` and the test filename is "test_my_project.c", then the
+generated function name will be `main_test_my_project(int argc, char** argv)`.
+
+This option can also be specified at the command prompt as `--main_name=""`
+
+##### `main_export_decl`
+
+Provide any `cdecl` for the `main()` test function. Is empty by default.
+
+##### `:omit_begin_end`
+
+If `true`, the `UnityBegin` and `UnityEnd` function will not be called for
+Unity test state setup and cleanup.
+
+This option can also be specified at the command prompt as `--omit_begin_end`
+
+##### `:shuffle_tests`
+
+If `true`, the test execution order will be shuffled. Is `false` by default.
+
+This option can also be specified at the command prompt as `--shuffle_tests`
+
+##### `:rng_seed`
+
+If set to some positive integer value, said value will be used as the seed value passed
+to the `srand` function. Otherwise, if not set to any value, `time(NULL)` will be used
+as the seed value.
+
+Only applicable if `:shuffle_tests` is set to `true`.
+
+This option can also be specified at the command prompt as `--rng_seed`
+
+#### Parameterized tests provided macros
+
+Unity provides support for few param tests generators, that can be combined
+with each other. You must define test function as usual C function with usual
+C arguments, and test generator will pass what you tell as a list of arguments.
+
+Let's show how all of them work on the following test function definitions:
+
+```C
+/* Place your test generators here, usually one generator per one or few lines */
+void test_demoParamFunction(int a, int b, int c)
+{
+  TEST_ASSERT_GREATER_THAN_INT(a + b, c);
+}
+```
+
+##### `TEST_CASE`
+
+Test case is a basic generator, that can be used for param testing.
+One call of that macro will generate only one call for test function.
+It can be used with different args, such as numbers, enums, strings,
+global variables, another preprocessor defines.
+
+If we use replace comment before test function with the following code:
+
+```C
+TEST_CASE(1, 2, 5)
+TEST_CASE(10, 7, 20)
+```
+
+script will generate 2 test calls:
+
+```C
+test_demoParamFunction(1, 2, 5);
+test_demoParamFunction(10, 7, 20);
+```
+
+That calls will be wrapped with `setUp`, `tearDown` and other
+usual Unity calls, as for independent unit tests.
+The following output can be generated after test executable startup:
+
+```Log
+tests/test_unity_parameterizedDemo.c:14:test_demoParamFunction(1, 2, 5):PASS
+tests/test_unity_parameterizedDemo.c:14:test_demoParamFunction(10, 7, 20):PASS
+```
+
+##### `TEST_RANGE`
+
+Test range is an advanced generator. It single call can be converted to zero,
+one or few `TEST_CASE` equivalent commands.
+
+That generator can be used for creating numeric ranges in decimal representation
+only: integers & floating point numbers. It uses few formats for every parameter:
+
+1. `[start, stop, step]` is stop-inclusive format
+2. `<start, stop, step>` is stop-exclusive formats
+
+Format providers 1 and 2 accept only three arguments:
+
+* `start` is start number
+* `stop` is end number (can or cannot exists in result sequence for format 1,
+will be always skipped for format 2)
+* `step` is incrementing step: can be either positive or negative value.
+
+Let's use our `test_demoParamFunction` test for checking, what ranges
+will be generated for our single `TEST_RANGE` row:
+
+```C
+TEST_RANGE([3, 4, 1], [10, 5, -2], <30, 31, 1>)
+```
+
+Tests execution output will be similar to that text:
+
+```Log
+tests/test_unity_parameterizedDemo.c:14:test_demoParamFunction(3, 10, 30):PASS
+tests/test_unity_parameterizedDemo.c:14:test_demoParamFunction(3, 8, 30):PASS
+tests/test_unity_parameterizedDemo.c:14:test_demoParamFunction(3, 6, 30):PASS
+tests/test_unity_parameterizedDemo.c:14:test_demoParamFunction(4, 10, 30):PASS
+tests/test_unity_parameterizedDemo.c:14:test_demoParamFunction(4, 8, 30):PASS
+tests/test_unity_parameterizedDemo.c:14:test_demoParamFunction(4, 6, 30):PASS
+```
+
+As we can see:
+
+| Parameter | Format | Possible values | Total of values | Format number |
+|---|---|---|---|---|
+| `a` | `[3, 4, 1]` | `3`, `4` | 2 | Format 1 |
+| `b` | `[10, 5, -2]` | `10`, `8`, `6` | 3 | Format 1, negative step, end number is not included |
+| `c` | `<30, 31, 1>` | `30` | 1 | Format 2 |
+
+_Note_, that format 2 also supports negative step.
+
+We totally have 2 * 3 * 1 = 6 equal test cases, that can be written as following:
+
+```C
+TEST_CASE(3, 10, 30)
+TEST_CASE(3, 8, 30)
+TEST_CASE(3, 6, 30)
+TEST_CASE(4, 10, 30)
+TEST_CASE(4, 8, 30)
+TEST_CASE(4, 6, 30)
+```
+
+##### `TEST_MATRIX`
+
+Test matix is an advanced generator. It single call can be converted to zero,
+one or few `TEST_CASE` equivalent commands.
+
+That generator will create tests for all combinations of the provided list. Each argument has to be given as a list of one or more elements in the format `[<parm1>, <param2>, ..., <paramN-1>, <paramN>]`.
+
+All parameters supported by the `TEST_CASE` are supported as arguments:
+- Numbers incl type specifiers e.g. `<1>`, `<1u>`, `<1l>`, `<2.3>`, or `<2.3f>`
+- Strings incl string concatenation e.g. `<"string">`, or `<"partial" "string">`
+- Chars e.g. `<'c'>`
+- Enums e.g. `<ENUM_NAME>`
+- Elements of arrays e.g. `<data[0]>`
+
+Let's use our `test_demoParamFunction` test for checking what ranges
+will be generated for our single `TEST_MATRIX` row:
+
+```C
+TEST_MATRIX([3, 4, 7], [10, 8, 2, 1],[30u, 20.0f])
+```
+
+Tests execution output will be similar to that text:
+
+```Log
+tests/test_unity_parameterizedDemo.c:18:test_demoParamFunction(3, 10, 30u):PASS
+tests/test_unity_parameterizedDemo.c:18:test_demoParamFunction(3, 10, 20.0f):PASS
+tests/test_unity_parameterizedDemo.c:18:test_demoParamFunction(3, 8, 30u):PASS
+tests/test_unity_parameterizedDemo.c:18:test_demoParamFunction(3, 8, 20.0f):PASS
+tests/test_unity_parameterizedDemo.c:18:test_demoParamFunction(3, 2, 30u):PASS
+tests/test_unity_parameterizedDemo.c:18:test_demoParamFunction(3, 2, 20.0f):PASS
+tests/test_unity_parameterizedDemo.c:18:test_demoParamFunction(3, 1, 30u):PASS
+tests/test_unity_parameterizedDemo.c:18:test_demoParamFunction(3, 1, 20.0f):PASS
+tests/test_unity_parameterizedDemo.c:18:test_demoParamFunction(4, 10, 30u):PASS
+tests/test_unity_parameterizedDemo.c:18:test_demoParamFunction(4, 10, 20.0f):PASS
+tests/test_unity_parameterizedDemo.c:18:test_demoParamFunction(4, 8, 30u):PASS
+tests/test_unity_parameterizedDemo.c:18:test_demoParamFunction(4, 8, 20.0f):PASS
+tests/test_unity_parameterizedDemo.c:18:test_demoParamFunction(4, 2, 30u):PASS
+tests/test_unity_parameterizedDemo.c:18:test_demoParamFunction(4, 2, 20.0f):PASS
+tests/test_unity_parameterizedDemo.c:18:test_demoParamFunction(4, 1, 30u):PASS
+tests/test_unity_parameterizedDemo.c:18:test_demoParamFunction(4, 1, 20.0f):PASS
+tests/test_unity_parameterizedDemo.c:18:test_demoParamFunction(7, 10, 30u):PASS
+tests/test_unity_parameterizedDemo.c:18:test_demoParamFunction(7, 10, 20.0f):PASS
+tests/test_unity_parameterizedDemo.c:18:test_demoParamFunction(7, 8, 30u):PASS
+tests/test_unity_parameterizedDemo.c:18:test_demoParamFunction(7, 8, 20.0f):PASS
+tests/test_unity_parameterizedDemo.c:18:test_demoParamFunction(7, 2, 30u):PASS
+tests/test_unity_parameterizedDemo.c:18:test_demoParamFunction(7, 2, 20.0f):PASS
+tests/test_unity_parameterizedDemo.c:18:test_demoParamFunction(7, 1, 30u):PASS
+tests/test_unity_parameterizedDemo.c:18:test_demoParamFunction(7, 1, 20.0f):PASS
+```
+
+As we can see:
+
+| Parameter | Format | Count of values |
+|---|---|---|
+| `a` | `[3, 4, 7]` | 3 |
+| `b` | `[10, 8, 2, 1]` | 4 |
+| `c` | `[30u, 20.0f]` | 2 |
+
+We totally have 3 * 4 * 2 = 24 equal test cases, that can be written as following:
+
+```C
+TEST_CASE(3, 10, 30u)
+TEST_CASE(3, 10, 20.0f)
+TEST_CASE(3, 8, 30u)
+TEST_CASE(3, 8, 20.0f)
+TEST_CASE(3, 2, 30u)
+TEST_CASE(3, 2, 20.0f)
+TEST_CASE(3, 1, 30u)
+TEST_CASE(3, 1, 20.0f)
+TEST_CASE(4, 10, 30u)
+TEST_CASE(4, 10, 20.0f)
+TEST_CASE(4, 8, 30u)
+TEST_CASE(4, 8, 20.0f)
+TEST_CASE(4, 2, 30u)
+TEST_CASE(4, 2, 20.0f)
+TEST_CASE(4, 1, 30u)
+TEST_CASE(4, 1, 20.0f)
+TEST_CASE(7, 10, 30u)
+TEST_CASE(7, 10, 20.0f)
+TEST_CASE(7, 8, 30u)
+TEST_CASE(7, 8, 20.0f)
+TEST_CASE(7, 2, 30u)
+TEST_CASE(7, 2, 20.0f)
+TEST_CASE(7, 1, 30u)
+TEST_CASE(7, 1, 20.0f)
+```
 
 ### `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.
+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.
+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:
+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/
@@ -249,7 +516,7 @@ 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\
+ruby unity_test_summary.rb build\test\ C:\projects\myproject\
 ```
 
 When configured correctly, you'll see a final summary, like so:
@@ -274,5 +541,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-lang.org/
+[YAML]: http://www.yaml.org/
+[Ceedling]: http://www.throwtheswitch.org/ceedling
+[ThrowTheSwitch.org]: https://throwtheswitch.org

docs/UnityKnownIssues.md

@@ -0,0 +1,13 @@
+# Unity Test - Known Issues
+
+## A Note
+
+This project will do its best to keep track of significant bugs that might effect your usage of this
+project and its supporting scripts. A more detailed and up-to-date list for cutting edge Unity can
+be found on our Github repository.
+
+## Issues
+
+  - No built-in validation of no-return functions
+  - Incomplete support for Printf-style formatting
+  - Incomplete support for VarArgs

examples/example_1/makefile

@@ -1,8 +1,9 @@
-# ==========================================
-#   Unity Project - A Test Framework for C
-#   Copyright (c) 2007 Mike Karlesky, Mark VanderVoord, Greg Williams
-#   [Released under MIT License. Please refer to license.txt for details]
-# ==========================================
+# =========================================================================
+#   Unity - A Test Framework for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2007-24 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
 
 #We try to detect the OS we are running on, and adjust commands as needed
 ifeq ($(OS),Windows_NT)

examples/example_1/meson.build

@@ -0,0 +1,48 @@
+project('Unity example', 'c',
+  license: 'MIT',
+  default_options: [
+    'c_std=c99',
+    'warning_level=3',
+  ],
+  meson_version: '>= 0.49.0'
+)
+
+unity_subproject = subproject('unity')
+unity_dependency = unity_subproject.get_variable('unity_dep')
+unity_gen_runner = unity_subproject.get_variable('gen_test_runner')
+
+src1 = files([
+  'src' / 'ProductionCode.c',
+  'test' / 'TestProductionCode.c',
+])
+
+src2 = files([
+  'src' / 'ProductionCode2.c',
+  'test' / 'TestProductionCode2.c',
+])
+
+inc = include_directories('src')
+
+test1 = executable('test1',
+  sources: [
+    src1,
+    unity_gen_runner.process('test' / 'TestProductionCode.c')
+  ],
+  include_directories: [ inc ],
+  dependencies: [ unity_dependency ],
+)
+
+test('test1', test1,
+  should_fail: true)
+
+test2 = executable('test2',
+  sources: [
+    src2,
+    unity_gen_runner.process('test' / 'TestProductionCode2.c')
+  ],
+  include_directories: [ inc ],
+  dependencies: [ unity_dependency ],
+)
+
+test('test2', test2)
+

examples/example_1/readme.txt

@@ -2,4 +2,11 @@ Example 1
 =========
 
 Close to the simplest possible example of Unity, using only basic features.
-Run make to build & run the example tests.
+
+Build and run with Make
+---
+Just run `make`.
+
+Build and run with Meson
+---
+Run `meson setup build` to create the build directory, and then `meson test -C build` to build and run the tests.

examples/example_1/src/ProductionCode.c

@@ -1,3 +1,9 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 #include "ProductionCode.h"
 

examples/example_1/src/ProductionCode.h

@@ -1,3 +1,9 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 int FindFunction_WhichIsBroken(int NumberToFind);
 int FunctionWhichReturnsLocalVariable(void);

examples/example_1/src/ProductionCode2.c

@@ -1,3 +1,9 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 #include "ProductionCode2.h"
 

examples/example_1/src/ProductionCode2.h

@@ -1,2 +1,8 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 char* ThisFunctionHasNotBeenTested(int Poor, char* LittleFunction);

examples/example_1/subprojects/unity.wrap

@@ -0,0 +1,3 @@
+[wrap-git]
+url = https://github.com/ThrowTheSwitch/Unity.git
+revision = head

examples/example_1/test/TestProductionCode.c

@@ -1,3 +1,9 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 #include "ProductionCode.h"
 #include "unity.h"

examples/example_1/test/TestProductionCode2.c

@@ -1,3 +1,9 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 #include "ProductionCode2.h"
 #include "unity.h"

examples/example_2/makefile

@@ -1,8 +1,9 @@
-# ==========================================
-#   Unity Project - A Test Framework for C
-#   Copyright (c) 2007 Mike Karlesky, Mark VanderVoord, Greg Williams
-#   [Released under MIT License. Please refer to license.txt for details]
-# ==========================================
+# =========================================================================
+#   Unity - A Test Framework for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2007-24 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
 
 #We try to detect the OS we are running on, and adjust commands as needed
 ifeq ($(OS),Windows_NT)

examples/example_2/src/ProductionCode.c

@@ -1,3 +1,9 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 #include "ProductionCode.h"
 

examples/example_2/src/ProductionCode.h

@@ -1,3 +1,9 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 int FindFunction_WhichIsBroken(int NumberToFind);
 int FunctionWhichReturnsLocalVariable(void);

examples/example_2/src/ProductionCode2.c

@@ -1,3 +1,9 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 #include "ProductionCode2.h"
 

examples/example_2/src/ProductionCode2.h

@@ -1,2 +1,8 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 char* ThisFunctionHasNotBeenTested(int Poor, char* LittleFunction);

examples/example_2/test/TestProductionCode.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "ProductionCode.h"
 #include "unity.h"
 #include "unity_fixture.h"

examples/example_2/test/TestProductionCode2.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "ProductionCode2.h"
 #include "unity.h"
 #include "unity_fixture.h"

examples/example_2/test/test_runners/TestProductionCode2_Runner.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "unity.h"
 #include "unity_fixture.h"
 

examples/example_2/test/test_runners/TestProductionCode_Runner.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "unity.h"
 #include "unity_fixture.h"
 

examples/example_2/test/test_runners/all_tests.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "unity_fixture.h"
 
 static void RunAllTests(void)

examples/example_3/helper/UnityHelper.c

@@ -1,3 +1,10 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #include "unity.h"
 #include "UnityHelper.h"
 #include <stdio.h>

examples/example_3/helper/UnityHelper.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 #ifndef _TESTHELPER_H
 #define _TESTHELPER_H
 

examples/example_3/rakefile.rb

@@ -1,3 +1,10 @@
+# =========================================================================
+#   Unity - A Test Framework for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
+
 require 'rake'
 require 'rake/clean'
 require_relative 'rakefile_helper'

examples/example_3/rakefile_helper.rb

@@ -1,18 +1,24 @@
-require 'yaml'
+# =========================================================================
+#   Unity - A Test Framework for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
+
 require 'fileutils'
 require_relative '../../auto/unity_test_summary'
 require_relative '../../auto/generate_test_runner'
 require_relative '../../auto/colour_reporter'
-
+require_relative '../../auto/yaml_helper'
 C_EXTENSION = '.c'.freeze
 
 def load_configuration(config_file)
   $cfg_file = config_file
-  $cfg = YAML.load(File.read($cfg_file))
+  $cfg = YamlHelper.load_file($cfg_file)
 end
 
 def configure_clean
-  CLEAN.include($cfg['compiler']['build_path'] + '*.*') unless $cfg['compiler']['build_path'].nil?
+  CLEAN.include("#{$cfg['compiler']['build_path']}*.*") unless $cfg['compiler']['build_path'].nil?
 end
 
 def configure_toolchain(config_file = DEFAULT_CONFIG_FILE)
@@ -22,7 +28,7 @@ def configure_toolchain(config_file = DEFAULT_CONFIG_FILE)
 end
 
 def unit_test_files
-  path = $cfg['compiler']['unit_tests_path'] + 'Test*' + C_EXTENSION
+  path = "#{$cfg['compiler']['unit_tests_path']}Test*#{C_EXTENSION}"
   path.tr!('\\', '/')
   FileList.new(path)
 end
@@ -37,7 +43,7 @@ def extract_headers(filename)
   includes = []
   lines = File.readlines(filename)
   lines.each do |line|
-    m = line.match(/^\s*#include\s+\"\s*(.+\.[hH])\s*\"/)
+    m = line.match(/^\s*#include\s+"\s*(.+\.[hH])\s*"/)
     includes << m[1] unless m.nil?
   end
   includes
@@ -52,12 +58,11 @@ def find_source_file(header, paths)
 end
 
 def tackit(strings)
-  result = if strings.is_a?(Array)
-             "\"#{strings.join}\""
-           else
-             strings
-           end
-  result
+  if strings.is_a?(Array)
+    "\"#{strings.join}\""
+  else
+    strings
+  end
 end
 
 def squash(prefix, items)
@@ -75,7 +80,7 @@ def build_compiler_fields
             end
   options = squash('', $cfg['compiler']['options'])
   includes = squash($cfg['compiler']['includes']['prefix'], $cfg['compiler']['includes']['items'])
-  includes = includes.gsub(/\\ /, ' ').gsub(/\\\"/, '"').gsub(/\\$/, '') # Remove trailing slashes (for IAR)
+  includes = includes.gsub(/\\ /, ' ').gsub(/\\"/, '"').gsub(/\\$/, '') # Remove trailing slashes (for IAR)
 
   { command: command, defines: defines, options: options, includes: includes }
 end
@@ -100,18 +105,18 @@ def build_linker_fields
                ''
              else
                squash($cfg['linker']['includes']['prefix'], $cfg['linker']['includes']['items'])
-             end.gsub(/\\ /, ' ').gsub(/\\\"/, '"').gsub(/\\$/, '') # Remove trailing slashes (for IAR)
+             end.gsub(/\\ /, ' ').gsub(/\\"/, '"').gsub(/\\$/, '') # Remove trailing slashes (for IAR)
 
   { command: command, options: options, includes: includes }
 end
 
 def link_it(exe_name, obj_list)
   linker = build_linker_fields
-  cmd_str = "#{linker[:command]}#{linker[:options]}#{linker[:includes]} " +
-            (obj_list.map { |obj| "#{$cfg['linker']['object_files']['path']}#{obj} " }).join +
-            $cfg['linker']['bin_files']['prefix'] + ' ' +
-            $cfg['linker']['bin_files']['destination'] +
-            exe_name + $cfg['linker']['bin_files']['extension']
+  cmd_str = "#{linker[:command]}#{linker[:options]}#{linker[:includes]}"
+  cmd_str += " #{(obj_list.map { |obj| "#{$cfg['linker']['object_files']['path']}#{obj}" }).join(' ')}"
+  cmd_str += " #{$cfg['linker']['bin_files']['prefix']} "
+  cmd_str += $cfg['linker']['bin_files']['destination']
+  cmd_str += exe_name + $cfg['linker']['bin_files']['extension']
   execute(cmd_str)
 end
 
@@ -121,7 +126,7 @@ def build_simulator_fields
   command = if $cfg['simulator']['path'].nil?
               ''
             else
-              (tackit($cfg['simulator']['path']) + ' ')
+              "#{tackit($cfg['simulator']['path'])} "
             end
   pre_support = if $cfg['simulator']['pre_support'].nil?
                   ''
@@ -184,7 +189,7 @@ def run_tests(test_files)
 
     # Build the test runner (generate if configured to do so)
     test_base = File.basename(test, C_EXTENSION)
-    runner_name = test_base + '_Runner.c'
+    runner_name = "#{test_base}_Runner.c"
     if $cfg['compiler']['runner_path'].nil?
       runner_path = $cfg['compiler']['build_path'] + runner_name
       test_gen = UnityTestRunnerGenerator.new($cfg_file)

examples/example_3/src/ProductionCode.c

@@ -1,3 +1,9 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 #include "ProductionCode.h"
 

examples/example_3/src/ProductionCode.h

@@ -1,3 +1,9 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 int FindFunction_WhichIsBroken(int NumberToFind);
 int FunctionWhichReturnsLocalVariable(void);

examples/example_3/src/ProductionCode2.c

@@ -1,3 +1,9 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 #include "ProductionCode2.h"
 

examples/example_3/src/ProductionCode2.h

@@ -1,2 +1,8 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 char* ThisFunctionHasNotBeenTested(int Poor, char* LittleFunction);

examples/example_3/target_gcc_32.yml

@@ -1,3 +1,10 @@
+# =========================================================================
+#   Unity - A Test Framework for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
+
 # Copied from ~Unity/targets/gcc_32.yml
 unity_root:  &unity_root '../..'
 unity_source: &unity_source '../../src/'

examples/example_3/test/TestProductionCode.c

@@ -1,3 +1,9 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 #include "ProductionCode.h"
 #include "unity.h"

examples/example_3/test/TestProductionCode2.c

@@ -1,3 +1,9 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 #include "ProductionCode2.h"
 #include "unity.h"

examples/example_4/meson.build

@@ -4,9 +4,9 @@
 #
 # license: MIT
 #
-project('example-4', 'c')
+project('example-4', 'c', meson_version: '>= 0.55.0')
 
-unity_dep = dependency('unity', fallback : ['unity', 'unity_dep'])
+unity_dep = dependency('unity')
 
 subdir('src')
 subdir('test')

examples/example_4/src/ProductionCode.c

@@ -1,3 +1,9 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 #include "ProductionCode.h"
 

examples/example_4/src/ProductionCode.h

@@ -1,3 +1,9 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 int FindFunction_WhichIsBroken(int NumberToFind);
 int FunctionWhichReturnsLocalVariable(void);

examples/example_4/src/ProductionCode2.c

@@ -1,3 +1,9 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 #include "ProductionCode2.h"
 

examples/example_4/src/ProductionCode2.h

@@ -1,2 +1,8 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 char* ThisFunctionHasNotBeenTested(int Poor, char* LittleFunction);

examples/example_4/subprojects/unity.wrap

@@ -1,4 +1,6 @@
 [wrap-git]
-directory = unity
 url = https://github.com/ThrowTheSwitch/Unity.git
 revision = head
+
+[provide]
+unity = unity_dep

examples/example_4/test/TestProductionCode.c

@@ -1,3 +1,9 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 #include "ProductionCode.h"
 #include "unity.h"

examples/example_4/test/TestProductionCode2.c

@@ -1,3 +1,9 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 #include "ProductionCode2.h"
 #include "unity.h"

examples/example_4/test/test_runners/meson.build

@@ -5,9 +5,9 @@
 # license: MIT
 #
 cases = [
-          ['TestProductionCode_Runner.c',  join_paths('..' ,'TestProductionCode.c' )], 
+          ['TestProductionCode_Runner.c',  join_paths('..' ,'TestProductionCode.c' )],
           ['TestProductionCode2_Runner.c', join_paths('..' ,'TestProductionCode2.c')]
         ]
 
-test('Running: 01-test-case', executable('01-test-case', cases[0], dependencies: [ a_dep, unity_dep ]))
-test('Running: 02-test-case', executable('02-test-case', cases[1], dependencies: [ b_dep, unity_dep ]))
+test('01-test-case', executable('01-test-case', cases[0], dependencies: [ a_dep, unity_dep ]))
+test('02-test-case', executable('02-test-case', cases[1], dependencies: [ b_dep, unity_dep ]))

examples/example_5/makefile

@@ -0,0 +1,63 @@
+# =========================================================================
+#   Unity - A Test Framework for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2007-24 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
+
+#We try to detect the OS we are running on, and adjust commands as needed
+ifeq ($(OS),Windows_NT)
+  ifeq ($(shell uname -s),) # not in a bash-like shell
+	CLEANUP = del /F /Q
+	MKDIR = mkdir
+  else # in a bash-like shell, like msys
+	CLEANUP = rm -f
+	MKDIR = mkdir -p
+  endif
+	TARGET_EXTENSION=.exe
+else
+	CLEANUP = rm -f
+	MKDIR = mkdir -p
+	TARGET_EXTENSION=.out
+endif
+
+C_COMPILER=gcc
+ifeq ($(shell uname -s), Darwin)
+C_COMPILER=clang
+endif
+
+UNITY_ROOT=../..
+
+CFLAGS=-std=c89
+CFLAGS += -Wall
+CFLAGS += -Wextra
+CFLAGS += -Wpointer-arith
+CFLAGS += -Wcast-align
+CFLAGS += -Wwrite-strings
+CFLAGS += -Wswitch-default
+CFLAGS += -Wunreachable-code
+CFLAGS += -Winit-self
+CFLAGS += -Wmissing-field-initializers
+CFLAGS += -Wno-unknown-pragmas
+CFLAGS += -Wstrict-prototypes
+CFLAGS += -Wundef
+CFLAGS += -Wold-style-definition
+#CFLAGS += -Wno-misleading-indentation
+
+
+TARGET_BASE1=test1
+TARGET1 = $(TARGET_BASE1)$(TARGET_EXTENSION)
+SRC_FILES1=$(UNITY_ROOT)/src/unity.c src/ProductionCode.c  test/TestProductionCode.c  test/test_runners/TestProductionCode_Runner.c
+INC_DIRS=-Isrc -I$(UNITY_ROOT)/src
+SYMBOLS=-include"test/unity_detail_config.h" -DUNIT_TESTING
+
+all: clean default
+
+default: $(SRC_FILES1)
+	$(C_COMPILER) $(CFLAGS) $(INC_DIRS) $(SYMBOLS) $(SRC_FILES1) -o $(TARGET1)
+	- ./$(TARGET1)
+clean:
+	$(CLEANUP) $(TARGET1) $(TARGET2)
+
+ci: CFLAGS += -Werror
+ci: default

examples/example_5/readme.txt

@@ -0,0 +1,38 @@
+Example 5
+=========
+
+Demonstrate Details Stack usage to implement something similar to a stacktrace.
+This allows locating the error source much faster in branching/iterating code.
+
+Build and run with Make
+---
+Just run `make`.
+
+Output
+---
+Below the output is annotated with source of the elements.
+
+```
+test/TestProductionCode.c:36:test_BitExtractor:FAIL: Expected 0 Was 1. During call BitExtractor. During call BitExtractor_down. Bit Position 6. Bit Mask 0x02. Unexpected bit value
+```
+
+| String                      | Source                                                                    |
+|-----------------------------|---------------------------------------------------------------------------|
+| `test/TestProductionCode.c` | `Unity.TestFile`                                                          |
+| `36`                        | `UNITY_TEST_ASSERT_EQUAL_INT` line                                        |
+| `test_BitExtractor`         | `RUN_TEST` name                                                           |
+| `FAIL`                      | `UnityStrFail`                                                            |
+| `Expected 1 Was 0`          | `UnityAssertEqualNumber`                                                  |
+| `During call`               | Detail 0, Label                                                           |
+| `BitExtractor`              | Detail 0, Value                                                           |
+| `During call`               | Detail 0, Label                                                           |
+| `BitExtractor`              | Detail 0, Value                                                           |
+| `During call`               | Detail 1, Label                                                           |
+| `BitExtractor_down`         | Detail 1, Value                                                           |
+| `Bit Position`              | Detail 2, Label (literal starts with #\x18, so value is printed as INT32) |
+| `6`                         | Detail 2 Value                                                            |
+| `Bit Mask`                  | Detail 2, Label (literal starts with #\x41, so value is printed as HEX8)  |
+| `0x02`                      | Detail 2 Value                                                            |
+| `Unexpected bit value`      | `UNITY_TEST_ASSERT_EQUAL_INT` message                                     |
+
+While this example is a bit contrived, the source of the error can be clearly located to be within the `test_BitExtractor->BitExtractor->BitExtractor_down`

examples/example_5/src/ProductionCode.c

@@ -0,0 +1,56 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
+#include "ProductionCode.h"
+
+#include <stdint.h>
+
+#ifdef UNIT_TESTING
+#include "unity.h"
+#else
+/* No-Op when not testing */
+#define UNITY_DETAIL_PUSH
+#define UNITY_DETAIL_POP
+#endif
+
+static void BitExtractor_up(uint8_t input, callback_t cb)
+{
+    int32_t pos;
+    UNITY_DETAIL_PUSH(UNITY_DETAIL_CALL, __FUNCTION__);
+    for(pos=0; pos<8; pos++) {
+        UNITY_DETAIL_PUSH(UNITY_DETAIL_BIT_POS, pos);
+        UNITY_DETAIL_PUSH(UNITY_DETAIL_BIT_MASK, 1<<pos);
+        cb(pos, !!(input & (1<<pos)));
+        UNITY_DETAIL_POP(UNITY_DETAIL_BIT_MASK, 1<<pos);
+        UNITY_DETAIL_POP(UNITY_DETAIL_BIT_POS, pos);
+    }
+    UNITY_DETAIL_POP(UNITY_DETAIL_CALL, __FUNCTION__);
+}
+
+static void BitExtractor_down(uint8_t input, callback_t cb)
+{
+    int32_t pos;
+    UNITY_DETAIL_PUSH(UNITY_DETAIL_CALL, __FUNCTION__);
+    for(pos=0; pos<8; pos++) {
+        UNITY_DETAIL_PUSH(UNITY_DETAIL_BIT_POS, pos);
+        UNITY_DETAIL_PUSH(UNITY_DETAIL_BIT_MASK, 0x80>>pos);
+        cb(pos, !!(input & (0x80>>pos)));
+        UNITY_DETAIL_POP(UNITY_DETAIL_BIT_MASK, 0x80>>pos);
+        UNITY_DETAIL_POP(UNITY_DETAIL_BIT_POS, pos);
+    }
+    UNITY_DETAIL_POP(UNITY_DETAIL_CALL, __FUNCTION__);
+}
+void BitExtractor(bit_direction_t dir, uint8_t input, callback_t cb)
+{
+    UNITY_DETAIL_PUSH(UNITY_DETAIL_CALL, __FUNCTION__);
+    if(dir == BIT_DIRECTION_UP) {
+        BitExtractor_up(input, cb);
+    } else {
+        BitExtractor_down(input, cb);
+    }
+    UNITY_DETAIL_POP(UNITY_DETAIL_CALL, __FUNCTION__);
+}

examples/example_5/src/ProductionCode.h

@@ -0,0 +1,16 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
+#include <stdint.h>
+
+typedef void callback_t(int position, int bit_value);
+typedef enum {
+    BIT_DIRECTION_UP,
+    BIT_DIRECTION_DOWN,
+} bit_direction_t;
+
+void BitExtractor(bit_direction_t dir, uint8_t input, callback_t cb);

examples/example_5/subprojects/unity.wrap

@@ -0,0 +1,3 @@
+[wrap-git]
+url = https://github.com/ThrowTheSwitch/Unity.git
+revision = head

examples/example_5/test/TestProductionCode.c

@@ -0,0 +1,45 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
+#include "ProductionCode.h"
+#include "unity.h"
+
+const int* current_expected_bits = NULL;
+UNITY_LINE_TYPE current_vector_line = 0;
+typedef struct {
+  UNITY_LINE_TYPE line;
+  uint8_t value;
+  bit_direction_t dir;
+  int expected_bits[8];
+} test_vector_t;
+
+void setUp(void)
+{
+}
+
+void tearDown(void)
+{
+}
+
+static void be_bit_tester(int position, int value) {
+  UNITY_TEST_ASSERT_EQUAL_INT(current_expected_bits[position], value, current_vector_line, "Unexpected bit value");
+}
+
+void test_BitExtractor(void)
+{
+  const test_vector_t test_vectors[] = {
+    {__LINE__, 7, BIT_DIRECTION_UP, {1,1,1,0,0,0,0,0}},
+    {__LINE__, 7, BIT_DIRECTION_DOWN, {0,0,0,0,0,1,0,1}},  /* intentionally wrong to demonstrate detail output */
+    {0}
+  };
+  const test_vector_t* tv;
+  for (tv = test_vectors; tv->line; tv++) {
+    current_vector_line = tv->line;
+    current_expected_bits = tv->expected_bits;
+    BitExtractor(tv->dir, tv->value, be_bit_tester);
+  }
+}

examples/example_5/test/test_runners/TestProductionCode_Runner.c

@@ -0,0 +1,48 @@
+/* AUTOGENERATED FILE. DO NOT EDIT. */
+
+/*=======Test Runner Used To Run Each Test Below=====*/
+#define RUN_TEST(TestFunc, TestLineNum) \
+{ \
+  Unity.CurrentTestName = #TestFunc; \
+  Unity.CurrentTestLineNumber = TestLineNum; \
+  Unity.NumberOfTests++; \
+  if (TEST_PROTECT()) \
+  { \
+      setUp(); \
+      TestFunc(); \
+  } \
+  if (TEST_PROTECT()) \
+  { \
+    tearDown(); \
+  } \
+  UnityConcludeTest(); \
+}
+
+/*=======Automagically Detected Files To Include=====*/
+#include "unity.h"
+#include <setjmp.h>
+#include <stdio.h>
+#include "ProductionCode.h"
+
+/*=======External Functions This Runner Calls=====*/
+extern void setUp(void);
+extern void tearDown(void);
+extern void test_BitExtractor(void);
+
+
+/*=======Test Reset Option=====*/
+void resetTest(void);
+void resetTest(void)
+{
+  tearDown();
+  setUp();
+}
+
+
+/*=======MAIN=====*/
+int main(void)
+{
+  UnityBegin("test/TestProductionCode.c");
+  RUN_TEST(test_BitExtractor, 32);
+  return UNITY_END();
+}

examples/example_5/test/unity_detail_config.h

@@ -0,0 +1,18 @@
+#define UNITY_DETAIL_STACK_SIZE  5
+#define LABEL_AS_INT32 "#\x18"  /*UNITY_DISPLAY_STYLE_INT32 = 0x18 */
+#define LABEL_AS_HEX8 "#\x41"   /* UNITY_DISPLAY_STYLE_HEX8 = 0x41 */
+#define UNITY_DETAIL_LABEL_NAMES { 0, \
+    UNITY_DETAIL1_NAME, \
+    UNITY_DETAIL2_NAME, \
+    "During call", \
+    LABEL_AS_INT32 "Bit Position", \
+    LABEL_AS_HEX8 "Bit Mask", \
+}
+typedef enum {
+    UNITY_DETAIL_NONE = 0,
+    UNITY_DETAIL_D1 = 1,
+    UNITY_DETAIL_D2 = 2,
+    UNITY_DETAIL_CALL,
+    UNITY_DETAIL_BIT_POS,
+    UNITY_DETAIL_BIT_MASK,
+} UNITY_DETAIL_LABEL_T;

examples/unity_config.h

@@ -1,3 +1,10 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
 /* Unity Configuration
  * As of May 11th, 2016 at ThrowTheSwitch/Unity commit 837c529
  * Update: December 29th, 2016
@@ -102,7 +109,7 @@
  * There can be a significant size and speed impact to enabling 64-bit support
  * on small targets, so don't define it if you don't need it.
  */
-/* #define UNITY_INCLUDE_64 */
+/* #define UNITY_SUPPORT_64 */
 
 
 /* *************************** FLOATING POINT TYPES ****************************

extras/bdd/readme.md

@@ -0,0 +1,40 @@
+# Unity Project - BDD Feature
+
+Unity's Behavior-Driven Development (BDD) test feature. It allows developers to structure and describe various phases (Given, When, Then) of a test scenario in a BDD-style format.
+
+## Introduction
+
+This project is based on the Unity framework originally created by Mike Karlesky, Mark VanderVoord, and Greg Williams in 2007. The project extends Unity by providing macros to define BDD structures with descriptive elements. Feature added by Michael Gene Brockus (Dreamer).
+
+## License
+
+This project is distributed under the MIT License. See the [license.txt](license.txt) file for more information.
+
+## Usage
+
+### BDD Macros
+
+The provided BDD macros allow you to structure your test scenarios in a descriptive manner. These macros are for descriptive purposes only and do not have functional behavior.
+
+- `GIVEN(description)`: Describes the "Given" phase of a test scenario.
+- `WHEN(description)`: Describes the "When" phase of a test scenario.
+- `THEN(description)`: Describes the "Then" phase of a test scenario.
+
+Example usage:
+
+```c
+GIVEN("a valid input") {
+    // Test setup and context
+    // ...
+
+    WHEN("the input is processed") {
+        // Perform the action
+        // ...
+
+        THEN("the expected outcome occurs") {
+            // Assert the outcome
+            // ...
+        }
+    }
+}
+```

extras/bdd/src/unity_bdd.h

@@ -0,0 +1,44 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
+#ifndef UNITY_BDD_TEST_H_
+#define UNITY_BDD_TEST_H_
+
+#ifdef __cplusplus
+extern "C"
+{
+#endif
+
+#include <stdio.h>
+
+/**
+ * @brief Macros for defining a Behavior-Driven Development (BDD) structure with descriptions.
+ *
+ * These macros provide a way to structure and describe different phases (Given, When, Then) of a
+ * test scenario in a BDD-style format. However, they don't have functional behavior by themselves
+ * and are used for descriptive purposes.
+ */
+#define GIVEN(description) \
+    if (0) { \
+        printf("Given %s\n", description); \
+    } else
+
+#define WHEN(description) \
+    if (0) { \
+        printf("When %s\n", description); \
+    } else
+
+#define THEN(description) \
+    if (0) { \
+        printf("Then %s\n", description); \
+    } else
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif 

extras/bdd/test/meson.build

@@ -0,0 +1,9 @@
+project('BDD Tester', 'c')
+
+# Add Unity as a dependency
+unity_dep = dependency('unity')
+
+# Define your source files
+sources = files('test_bdd.c')
+
+executable('tester', sources, dependencies : unity_dep)

extras/bdd/test/test_bdd.c

@@ -0,0 +1,129 @@
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
+#include "unity.h"
+#include "unity_bdd.h"
+
+void test_bdd_logic_test(void) {
+    GIVEN("a valid statement is passed")
+    {
+        // Set up the context
+        bool givenExecuted = true;
+
+        WHEN("a statement is true")
+        {
+            // Perform the login action
+            bool whenExecuted = true;
+            
+            THEN("we validate everything was worked")
+            {
+                // Check the expected outcome
+                bool thenExecuted = true;
+
+                TEST_ASSERT_TRUE(givenExecuted);
+                TEST_ASSERT_TRUE(whenExecuted);
+                TEST_ASSERT_TRUE(thenExecuted);
+            }
+        }
+    }
+} // end of case
+
+void test_bdd_user_account(void) {
+    GIVEN("a user's account with sufficient balance")
+    {
+        // Set up the context
+        float accountBalance = 500.0;
+        float withdrawalAmount = 200.0;
+
+        WHEN("the user requests a withdrawal of $200")
+        {
+            // Perform the withdrawal action
+            if (accountBalance >= withdrawalAmount)
+            {
+                accountBalance -= withdrawalAmount;
+            } // end if
+            THEN("the withdrawal amount should be deducted from the account balance")
+            {
+                // Check the expected outcome
+
+                // Simulate the scenario
+                float compareBalance = 500.0;
+                TEST_ASSERT_LESS_THAN_FLOAT(accountBalance, compareBalance);
+            }
+        }
+    }
+} // end of case
+
+void test_bdd_empty_cart(void) {
+    GIVEN("a user with an empty shopping cart")
+    {
+        // Set up the context
+        int cartItemCount = 0;
+
+        WHEN("the user adds a product to the cart")
+        {
+            // Perform the action of adding a product
+
+            THEN("the cart item count should increase by 1")
+            {
+                // Check the expected outcome
+                cartItemCount++;
+
+                TEST_ASSERT_EQUAL_INT(cartItemCount, 1);
+            }
+        }
+    }
+} // end of case
+
+void test_bdd_valid_login(void) {
+    GIVEN("a registered user with valid credentials")
+    {
+        // Set up the context
+        const char* validUsername = "user123";
+        const char* validPassword = "pass456";
+
+        WHEN("the user provides correct username and password")
+        {
+            // Perform the action of user login
+            const char* inputUsername = "user123";
+            const char* inputPassword = "pass456";
+
+            THEN("the login should be successful")
+            {
+                // Check the expected outcome
+                // Simulate login validation
+                TEST_ASSERT_EQUAL_STRING(inputUsername, validUsername);
+                TEST_ASSERT_EQUAL_STRING(inputPassword, validPassword);
+            }
+        }
+
+        WHEN("the user provides incorrect password")
+        {
+            // Perform the action of user login
+            const char* inputUsername = "user123";
+            const char* inputPassword = "wrongpass";
+
+            THEN("the login should fail with an error message")
+            {
+                // Check the expected outcome
+                // Simulate login validation
+                TEST_ASSERT_EQUAL_STRING(inputUsername, validUsername);
+                // TEST_ASSERT_NOT_EQUAL_STRING(inputPassword, validPassword);
+            }
+        }
+    }
+} // end of case
+
+int main(void)
+{
+    UnityBegin("test_bdd.c");
+    RUN_TEST(test_bdd_logic_test);
+    RUN_TEST(test_bdd_user_account);
+    RUN_TEST(test_bdd_empty_cart);
+    RUN_TEST(test_bdd_valid_login);
+    return UnityEnd();
+}

extras/fixture/readme.md

@@ -1,29 +1,26 @@
 # Unity Fixtures
 
-This Framework is an optional add-on to Unity.  By including unity_framework.h in place of unity.h,
-you may now work with Unity in a manner similar to CppUTest.  This framework adds the concepts of 
-test groups and gives finer control of your tests over the command line.
+This Framework is an optional add-on to Unity.
+By including unity_fixture.h in place of unity.h, you may now work with Unity in a manner similar to CppUTest.
+This framework adds the concepts of test groups and gives finer control of your tests over the command line.
 
-This framework is primarily supplied for those working through James Grenning's book on Embedded
-Test Driven Development, or those coming to Unity from CppUTest. We should note that using this
-framework glosses over some of the features of Unity, and makes it more difficult
-to integrate with other testing tools like Ceedling and CMock.
+This framework is primarily supplied for those working through James Grenning's book on Embedded Test Driven Development, or those coming to Unity from CppUTest.
+We should note that using this framework glosses over some of the features of Unity, and makes it more difficult to integrate with other testing tools like Ceedling and CMock.
 
-# Dependency Notification
+## Dependency Notification
 
-Fixtures, by default, uses the Memory addon as well. This is to make it simple for those trying to
-follow along with James' book. Using them together is completely optional. You may choose to use 
-Fixtures without Memory handling by defining `UNITY_FIXTURE_NO_EXTRAS`. It will then stop automatically
-pulling in extras and leave you to do it as desired.
+Fixtures, by default, uses the Memory addon as well.
+This is to make it simple for those trying to follow along with James' book.
+Using them together is completely optional.
+You may choose to use Fixtures without Memory handling by defining `UNITY_FIXTURE_NO_EXTRAS`.
+It will then stop automatically pulling in extras and leave you to do it as desired.
 
-# Usage information
+## Usage information
 
-By default the test executables produced by Unity Fixtures run all tests once, but the behavior can
-be configured with command-line flags. Run the test executable with the `--help` flag for more
-information.
+By default the test executables produced by Unity Fixtures run all tests once, but the behavior can be configured with command-line flags.
+Run the test executable with the `--help` flag for more information.
 
-It's possible to add a custom line at the end of the help message, typically to point to
-project-specific or company-specific unit test documentation. Define `UNITY_CUSTOM_HELP_MSG` to
-provide a custom message, e.g.:
+It's possible to add a custom line at the end of the help message, typically to point to project-specific or company-specific unit test documentation.
+Define `UNITY_CUSTOM_HELP_MSG` to provide a custom message, e.g.:
 
     #define UNITY_CUSTOM_HELP_MSG "If any test fails see https://example.com/troubleshooting"

extras/fixture/src/meson.build

@@ -0,0 +1,10 @@
+unity_inc += include_directories('.')
+unity_src += files('unity_fixture.c')
+
+if not meson.is_subproject()
+  install_headers(
+    'unity_fixture.h',
+    'unity_fixture_internals.h',
+    subdir: meson.project_name()
+  )
+endif

extras/fixture/src/unity_fixture.c

@@ -1,9 +1,9 @@
-/* Copyright (c) 2010 James Grenning and Contributed to Unity Project
- * ==========================================
- *  Unity Project - A Test Framework for C
- *  Copyright (c) 2007 Mike Karlesky, Mark VanderVoord, Greg Williams
- *  [Released under MIT License. Please refer to license.txt for details]
- * ========================================== */
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 #include "unity_fixture.h"
 #include "unity_internals.h"
@@ -46,21 +46,25 @@ int UnityMain(int argc, const char* argv[], void (*runAllTests)(void))
     return (int)Unity.TestFailures;
 }
 
-static int selected(const char* filter, const char* name)
+static int selected(const char* filter, const char* select, const char* name)
 {
-    if (filter == 0)
+    if (filter == 0 && select == 0)
         return 1;
-    return strstr(name, filter) ? 1 : 0;
+    if (filter && strstr(name, filter))
+        return 1;
+    if (select && strcmp(name, select) == 0)
+        return 1;
+    return 0;
 }
 
 static int testSelected(const char* test)
 {
-    return selected(UnityFixture.NameFilter, test);
+    return selected(UnityFixture.NameFilter, UnityFixture.Name, test);
 }
 
 static int groupSelected(const char* group)
 {
-    return selected(UnityFixture.GroupFilter, group);
+    return selected(UnityFixture.GroupFilter, UnityFixture.Group, group);
 }
 
 void UnityTestRunner(unityfunction* setup,
@@ -96,17 +100,20 @@ void UnityTestRunner(unityfunction* setup,
         Unity.NumberOfTests++;
         UnityPointer_Init();
 
-        UNITY_EXEC_TIME_START();
+        if (!UnityFixture.DryRun) {
+            UNITY_EXEC_TIME_START();
 
-        if (TEST_PROTECT())
-        {
-            setup();
-            testBody();
-        }
-        if (TEST_PROTECT())
-        {
-            teardown();
+            if (TEST_PROTECT())
+            {
+                setup();
+                testBody();
+            }
+            if (TEST_PROTECT())
+            {
+                teardown();
+            }
         }
+
         if (TEST_PROTECT())
         {
             UnityPointer_UndoAllSets();
@@ -183,8 +190,11 @@ int UnityGetCommandLineOptions(int argc, const char* argv[])
     int i;
     UnityFixture.Verbose = 0;
     UnityFixture.Silent = 0;
+    UnityFixture.DryRun = 0;
     UnityFixture.GroupFilter = 0;
+    UnityFixture.Group = 0;
     UnityFixture.NameFilter = 0;
+    UnityFixture.Name = 0;
     UnityFixture.RepeatCount = 1;
 
     if (argc == 1)
@@ -207,10 +217,16 @@ int UnityGetCommandLineOptions(int argc, const char* argv[])
             UNITY_PRINT_EOL();
             UnityPrint("  -s          Silent mode: minimal output showing only test failures");
             UNITY_PRINT_EOL();
+            UnityPrint("  -d          Dry run all tests");
+            UNITY_PRINT_EOL();
             UnityPrint("  -g NAME     Only run tests in groups that contain the string NAME");
             UNITY_PRINT_EOL();
+            UnityPrint("  -G NAME     Only run tests in groups named NAME");
+            UNITY_PRINT_EOL();
             UnityPrint("  -n NAME     Only run tests whose name contains the string NAME");
             UNITY_PRINT_EOL();
+            UnityPrint("  -N NAME     Only run tests named NAME");
+            UNITY_PRINT_EOL();
             UnityPrint("  -r NUMBER   Repeatedly run all tests NUMBER times");
             UNITY_PRINT_EOL();
             UnityPrint("  -h, --help  Display this help message");
@@ -237,6 +253,11 @@ int UnityGetCommandLineOptions(int argc, const char* argv[])
             UnityFixture.Silent = 1;
             i++;
         }
+        else if (strcmp(argv[i], "-d") == 0)
+        {
+            UnityFixture.DryRun = 1;
+            i++;
+        }
         else if (strcmp(argv[i], "-g") == 0)
         {
             i++;
@@ -245,6 +266,14 @@ int UnityGetCommandLineOptions(int argc, const char* argv[])
             UnityFixture.GroupFilter = argv[i];
             i++;
         }
+        else if (strcmp(argv[i], "-G") == 0)
+        {
+            i++;
+            if (i >= argc)
+                return 1;
+            UnityFixture.Group= argv[i];
+            i++;
+        }
         else if (strcmp(argv[i], "-n") == 0)
         {
             i++;
@@ -253,6 +282,14 @@ int UnityGetCommandLineOptions(int argc, const char* argv[])
             UnityFixture.NameFilter = argv[i];
             i++;
         }
+        else if (strcmp(argv[i], "-N") == 0)
+        {
+            i++;
+            if (i >= argc)
+                return 1;
+            UnityFixture.Name = argv[i];
+            i++;
+        }
         else if (strcmp(argv[i], "-r") == 0)
         {
             UnityFixture.RepeatCount = 2;

extras/fixture/src/unity_fixture.h

@@ -1,21 +1,28 @@
-/* Copyright (c) 2010 James Grenning and Contributed to Unity Project
- * ==========================================
- *  Unity Project - A Test Framework for C
- *  Copyright (c) 2007 Mike Karlesky, Mark VanderVoord, Greg Williams
- *  [Released under MIT License. Please refer to license.txt for details]
- * ========================================== */
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 #ifndef UNITY_FIXTURE_H_
 #define UNITY_FIXTURE_H_
 
 #include "unity.h"
-#include "unity_internals.h"
 #include "unity_fixture_internals.h"
 
 #ifndef UNITY_FIXTURE_NO_EXTRAS
 #include "unity_memory.h"
 #endif
 
+#ifdef __cplusplus
+extern "C"
+{
+#endif
+
+#include "unity_internals.h"
+
+
 int UnityMain(int argc, const char* argv[], void (*runAllTests)(void));
 
 
@@ -80,4 +87,8 @@ int UnityMain(int argc, const char* argv[], void (*runAllTests)(void));
 #define DOUBLES_EQUAL(expected, actual, delta)         TEST_ASSERT_DOUBLE_WITHIN((delta), (expected), (actual))
 #endif
 
+#ifdef __cplusplus
+}
+#endif
+
 #endif /* UNITY_FIXTURE_H_ */

extras/fixture/src/unity_fixture_internals.h

@@ -1,9 +1,9 @@
-/* Copyright (c) 2010 James Grenning and Contributed to Unity Project
- * ==========================================
- *  Unity Project - A Test Framework for C
- *  Copyright (c) 2007 Mike Karlesky, Mark VanderVoord, Greg Williams
- *  [Released under MIT License. Please refer to license.txt for details]
- * ========================================== */
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 #ifndef UNITY_FIXTURE_INTERNALS_H_
 #define UNITY_FIXTURE_INTERNALS_H_
@@ -17,9 +17,12 @@ struct UNITY_FIXTURE_T
 {
     int Verbose;
     int Silent;
+    int DryRun;
     unsigned int RepeatCount;
     const char* NameFilter;
+    const char* Name;
     const char* GroupFilter;
+    const char* Group;
 };
 extern struct UNITY_FIXTURE_T UnityFixture;
 

extras/fixture/test/main/AllTests.c

@@ -1,9 +1,9 @@
-/* Copyright (c) 2010 James Grenning and Contributed to Unity Project
- * ==========================================
- *  Unity Project - A Test Framework for C
- *  Copyright (c) 2007 Mike Karlesky, Mark VanderVoord, Greg Williams
- *  [Released under MIT License. Please refer to license.txt for details]
- * ========================================== */
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 #include "unity_fixture.h"
 

extras/fixture/test/template_fixture_tests.c

@@ -1,9 +1,9 @@
-/* Copyright (c) 2010 James Grenning and Contributed to Unity Project
- * ==========================================
- *  Unity Project - A Test Framework for C
- *  Copyright (c) 2007 Mike Karlesky, Mark VanderVoord, Greg Williams
- *  [Released under MIT License. Please refer to license.txt for details]
- * ========================================== */
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 #include "unity_fixture.h"
 

extras/fixture/test/unity_fixture_Test.c

@@ -1,9 +1,9 @@
-/* Copyright (c) 2010 James Grenning and Contributed to Unity Project
- * ==========================================
- *  Unity Project - A Test Framework for C
- *  Copyright (c) 2007 Mike Karlesky, Mark VanderVoord, Greg Williams
- *  [Released under MIT License. Please refer to license.txt for details]
- * ========================================== */
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 #include "unity_fixture.h"
 #include <stdlib.h>
@@ -90,23 +90,32 @@ TEST_GROUP(UnityCommandOptions);
 
 static int savedVerbose;
 static unsigned int savedRepeat;
+static int savedDryRun;
 static const char* savedName;
 static const char* savedGroup;
+static const char* savedNameExact;
+static const char* savedGroupExact;
 
 TEST_SETUP(UnityCommandOptions)
 {
     savedVerbose = UnityFixture.Verbose;
     savedRepeat = UnityFixture.RepeatCount;
+    savedDryRun = UnityFixture.DryRun;
     savedName = UnityFixture.NameFilter;
     savedGroup = UnityFixture.GroupFilter;
+    savedNameExact = UnityFixture.Name;
+    savedGroupExact = UnityFixture.Group;
 }
 
 TEST_TEAR_DOWN(UnityCommandOptions)
 {
     UnityFixture.Verbose = savedVerbose;
     UnityFixture.RepeatCount= savedRepeat;
+    UnityFixture.DryRun = savedDryRun;
     UnityFixture.NameFilter = savedName;
     UnityFixture.GroupFilter = savedGroup;
+    UnityFixture.Name= savedNameExact;
+    UnityFixture.Group= savedGroup;
 }
 
 
@@ -118,8 +127,11 @@ TEST(UnityCommandOptions, DefaultOptions)
 {
     UnityGetCommandLineOptions(1, noOptions);
     TEST_ASSERT_EQUAL(0, UnityFixture.Verbose);
+    TEST_ASSERT_EQUAL(0, UnityFixture.DryRun);
     TEST_ASSERT_POINTERS_EQUAL(0, UnityFixture.GroupFilter);
     TEST_ASSERT_POINTERS_EQUAL(0, UnityFixture.NameFilter);
+    TEST_ASSERT_POINTERS_EQUAL(0, UnityFixture.Group);
+    TEST_ASSERT_POINTERS_EQUAL(0, UnityFixture.Name);
     TEST_ASSERT_EQUAL(1, UnityFixture.RepeatCount);
 }
 
@@ -134,6 +146,17 @@ TEST(UnityCommandOptions, OptionVerbose)
     TEST_ASSERT_EQUAL(1, UnityFixture.Verbose);
 }
 
+static const char* dryRun[] = {
+        "testrunner.exe",
+        "-d"
+};
+
+TEST(UnityCommandOptions, OptionDryRun)
+{
+    TEST_ASSERT_EQUAL(0, UnityGetCommandLineOptions(2, dryRun));
+    TEST_ASSERT_EQUAL(1, UnityFixture.DryRun);
+}
+
 static const char* group[] = {
         "testrunner.exe",
         "-g", "groupname"
@@ -156,6 +179,28 @@ TEST(UnityCommandOptions, OptionSelectTestByName)
     STRCMP_EQUAL("testname", UnityFixture.NameFilter);
 }
 
+static const char* groupExact[] = {
+        "testrunner.exe",
+        "-G", "groupname"
+};
+
+TEST(UnityCommandOptions, OptionSelectTestByGroupExact)
+{
+    TEST_ASSERT_EQUAL(0, UnityGetCommandLineOptions(3, groupExact));
+    STRCMP_EQUAL("groupname", UnityFixture.Group);
+}
+
+static const char* nameExact[] = {
+        "testrunner.exe",
+        "-N", "testname"
+};
+
+TEST(UnityCommandOptions, OptionSelectTestByNameExact)
+{
+    TEST_ASSERT_EQUAL(0, UnityGetCommandLineOptions(3, nameExact));
+    STRCMP_EQUAL("testname", UnityFixture.Name);
+}
+
 static const char* repeat[] = {
         "testrunner.exe",
         "-r", "99"

extras/fixture/test/unity_fixture_TestRunner.c

@@ -1,9 +1,9 @@
-/* Copyright (c) 2010 James Grenning and Contributed to Unity Project
- * ==========================================
- *  Unity Project - A Test Framework for C
- *  Copyright (c) 2007 Mike Karlesky, Mark VanderVoord, Greg Williams
- *  [Released under MIT License. Please refer to license.txt for details]
- * ========================================== */
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 #include "unity_fixture.h"
 
@@ -19,8 +19,11 @@ TEST_GROUP_RUNNER(UnityCommandOptions)
 {
     RUN_TEST_CASE(UnityCommandOptions, DefaultOptions);
     RUN_TEST_CASE(UnityCommandOptions, OptionVerbose);
+    RUN_TEST_CASE(UnityCommandOptions, OptionDryRun);
     RUN_TEST_CASE(UnityCommandOptions, OptionSelectTestByGroup);
     RUN_TEST_CASE(UnityCommandOptions, OptionSelectTestByName);
+    RUN_TEST_CASE(UnityCommandOptions, OptionSelectTestByGroupExact);
+    RUN_TEST_CASE(UnityCommandOptions, OptionSelectTestByNameExact);
     RUN_TEST_CASE(UnityCommandOptions, OptionSelectRepeatTestsDefaultCount);
     RUN_TEST_CASE(UnityCommandOptions, OptionSelectRepeatTestsSpecificCount);
     RUN_TEST_CASE(UnityCommandOptions, MultipleOptions);

extras/memory/readme.md

@@ -1,49 +1,42 @@
 # Unity Memory
 
-This Framework is an optional add-on to Unity.  By including unity.h and then
-unity_memory.h, you have the added ability to track malloc and free calls. This 
-addon requires that the stdlib functions be overridden by its own defines. These
-defines will still malloc / realloc / free etc, but will also track the calls
-in order to ensure that you don't have any memory leaks in your programs.
+This Framework is an optional add-on to Unity.
+By including unity.h and then unity_memory.h, you have the added ability to track malloc and free calls.
+This addon requires that the stdlib functions be overridden by its own defines.
+These defines will still malloc / realloc / free etc, but will also track the calls in order to ensure that you don't have any memory leaks in your programs.
 
-Note that this is only useful in situations where a unit is in charge of both
-the allocation and deallocation of memory. When it is not symmetric, unit testing 
-can report a number of false failures. A more advanced runtime tool is required to
-track complete system memory handling.
+Note that this is only useful in situations where a unit is in charge of both the allocation and deallocation of memory.
+When it is not symmetric, unit testing can report a number of false failures.
+A more advanced runtime tool is required to track complete system memory handling.
 
-# Module API
+## Module API
 
-## `UnityMalloc_StartTest` and `UnityMalloc_EndTest`
+### `UnityMalloc_StartTest` and `UnityMalloc_EndTest`
 
-These must be called at the beginning and end of each test. For simplicity, they can
-be added to `setUp` and `tearDown` in order to do their job. When using the test
-runner generator scripts, these will be automatically added to the runner whenever
-unity_memory.h is included.
+These must be called at the beginning and end of each test.
+For simplicity, they can be added to `setUp` and `tearDown` in order to do their job.
+When using the test runner generator scripts, these will be automatically added to the runner whenever unity_memory.h is included.
 
-## `UnityMalloc_MakeMallocFailAfterCount`
+### `UnityMalloc_MakeMallocFailAfterCount`
 
-This can be called from the tests themselves. Passing this function a number will
-force the reference counter to start keeping track of malloc calls. During that test,
-if the number of malloc calls exceeds the number given, malloc will immediately 
-start returning `NULL`. This allows you to test error conditions. Think of it as a 
-simplified mock.
+This can be called from the tests themselves.
+Passing this function a number will force the reference counter to start keeping track of malloc calls.
+During that test, if the number of malloc calls exceeds the number given, malloc will immediately start returning `NULL`.
+This allows you to test error conditions.
+Think of it as a simplified mock.
 
-# Configuration
+## Configuration
 
-## `UNITY_MALLOC` and `UNITY_FREE`
+### `UNITY_MALLOC` and `UNITY_FREE`
 
-By default, this module tries to use the real stdlib `malloc` and `free` internally. 
-If you would prefer it to use something else, like FreeRTOS's `pvPortMalloc` and 
-`pvPortFree`, then you can use these defines to make it so.
+By default, this module tries to use the real stdlib `malloc` and `free` internally.
+If you would prefer it to use something else, like FreeRTOS's `pvPortMalloc` and `pvPortFree`, then you can use these defines to make it so.
 
-## `UNITY_EXCLUDE_STDLIB_MALLOC`
+### `UNITY_EXCLUDE_STDLIB_MALLOC`
 
-If you would like this library to ignore stdlib or other heap engines completely, and
-manage the memory on its own, then define this. All memory will be handled internally
-(and at likely lower overhead). Note that this is not a very featureful memory manager,
-but is sufficient for most testing purposes.
+If you would like this library to ignore stdlib or other heap engines completely, and manage the memory on its own, then define this. All memory will be handled internally (and at likely lower overhead).
+Note that this is not a very featureful memory manager, but is sufficient for most testing purposes.
 
-## `UNITY_INTERNAL_HEAP_SIZE_BYTES`
+### `UNITY_INTERNAL_HEAP_SIZE_BYTES`
 
-When using the built-in memory manager (see `UNITY_EXCLUDE_STDLIB_MALLOC`) this define
-allows you to set the heap size this library will use to manage the memory.
+When using the built-in memory manager (see `UNITY_EXCLUDE_STDLIB_MALLOC`) this define allows you to set the heap size this library will use to manage the memory.

extras/memory/src/meson.build

@@ -0,0 +1,9 @@
+unity_inc += include_directories('.')
+unity_src += files('unity_memory.c')
+
+if not meson.is_subproject()
+  install_headers(
+    'unity_memory.h',
+    subdir: meson.project_name()
+  )
+endif

extras/memory/src/unity_memory.c

@@ -1,8 +1,9 @@
-/* ==========================================
- *  Unity Project - A Test Framework for C
- *  Copyright (c) 2007 Mike Karlesky, Mark VanderVoord, Greg Williams
- *  [Released under MIT License. Please refer to license.txt for details]
- * ========================================== */
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 #include "unity.h"
 #include "unity_memory.h"

extras/memory/src/unity_memory.h

@@ -1,8 +1,9 @@
-/* ==========================================
- *  Unity Project - A Test Framework for C
- *  Copyright (c) 2007 Mike Karlesky, Mark VanderVoord, Greg Williams
- *  [Released under MIT License. Please refer to license.txt for details]
- * ========================================== */
+/* =========================================================================
+    Unity - A Test Framework for C
+    ThrowTheSwitch.org
+    Copyright (c) 2007-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
 
 #ifndef UNITY_MEMORY_OVERRIDES_H_
 #define UNITY_MEMORY_OVERRIDES_H_

extras/memory/test/Makefile

@@ -1,3 +1,10 @@
+# =========================================================================
+#    Unity - A Test Framework for C
+#    ThrowTheSwitch.org
+#    Copyright (c) 2007-24 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#    SPDX-License-Identifier: MIT
+# ========================================================================= 
+
 CC = gcc
 ifeq ($(shell uname -s), Darwin)
 CC = clang