Unity Documentation

File: README.md

Unity Test ![CI][]

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.

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.

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

text

TEST_ASSERT_TRUE(condition)

Evaluates whatever code is in condition and fails if it evaluates to false

text

TEST_ASSERT_FALSE(condition)

Evaluates whatever code is in condition and fails if it evaluates to true

text

TEST_ASSERT(condition)

Another way of calling TEST_ASSERT_TRUE

text

TEST_ASSERT_UNLESS(condition)

Another way of calling TEST_ASSERT_FALSE

text

TEST_FAIL()
TEST_FAIL_MESSAGE(message)

This test is automatically marked as a failure.
The message is output stating why.

Numerical Assertions: Integers

text

TEST_ASSERT_EQUAL_INT(expected, actual)
TEST_ASSERT_EQUAL_INT8(expected, actual)
TEST_ASSERT_EQUAL_INT16(expected, actual)
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, you can use a specific version.

text

TEST_ASSERT_EQUAL_UINT(expected, actual)
TEST_ASSERT_EQUAL_UINT8(expected, actual)
TEST_ASSERT_EQUAL_UINT16(expected, actual)
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.

text

TEST_ASSERT_EQUAL_HEX(expected, actual)
TEST_ASSERT_EQUAL_HEX8(expected, actual)
TEST_ASSERT_EQUAL_HEX16(expected, actual)
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 affect how many nibbles are shown (for example, HEX16 will show 4 nibbles).

text

TEST_ASSERT_EQUAL(expected, actual)

Another way of calling TEST_ASSERT_EQUAL_INT

text

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.

text

TEST_ASSERT_GREATER_THAN(threshold, actual)

Asserts that the actual value is greater than the threshold.
This also comes in size specific variants.

text

TEST_ASSERT_LESS_THAN(threshold, actual)

Asserts that the actual value is less than the threshold.
This also comes in size specific variants.

Arrays

text

_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:

text

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:

text

TEST_ASSERT_EACH_EQUAL_INT32(expected, actual, elements)

Numerical Assertions: Bitwise

text

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.

text

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.

text

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.

text

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.

text

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.

Numerical Assertions: Floats

text

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.

text

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.

text

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.

text

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.

text

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

text

TEST_ASSERT_EQUAL_STRING(expected, actual)

Compare two null-terminate strings.
Fail if any character is different or if the lengths are different.

text

TEST_ASSERT_EQUAL_STRING_LEN(expected, actual, len)

Compare two strings.
Fail if any character is different, stop comparing after len characters.

text

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.

text

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.

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.

text

TEST_ASSERT_NULL(pointer)

Fails if the pointer is not equal to NULL

text

TEST_ASSERT_NOT_NULL(pointer)

Fails if the pointer is equal to NULL

Memory Assertions

text

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.

\_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.

File: docs/CODE_OF_CONDUCT.md

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
[email protected].

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,
version 2.1, available at
https://www.contributor-covenant.org/version/2/1/code_of_conduct.html.

Community Impact Guidelines were inspired by
Mozilla's code of conduct enforcement ladder.

For answers to common questions about this code of conduct, see the FAQ at
https://www.contributor-covenant.org/faq. Translations are available at
https://www.contributor-covenant.org/translations.

File: docs/CONTRIBUTING.md

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.

Code of Conduct
Asking Questions
Opening an Issue
Feature Requests
Triaging Issues
Submitting Pull Requests
Writing Commit Messages
Code Review
Coding Style
Certificate of Origin
Credits

:book: Code of Conduct

Please review our Code of Conduct. 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

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 -- Build coordinator for testing C applications, especially embedded C (and optionally your release build too!)
CMock -- Mocking tool for automatically creating stubs, mocks, and skeletons in C
Unity -- Unit Testing framework for C, specially embedded C.
MadScienceLabDocker -- Docker image giving you a shortcut to getting running with Ceedling
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, 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, 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. Especially put code blocks and console outputs in backticks (```
/* Detailed source-code truncated for AI context efficiency. */

text

: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.

Ruby Styleguide

Ruby code is linted with Rubocop

:medal_sports: Certificate of Origin

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

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

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

The contribution was provided directly to me by some other person who certified (1), (2) or (3) and I have not modified it.

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. Lovingly adapted to ThrowTheSwitch.org by @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:

We commend them for their efforts to facilitate collaboration in their projects.

File: docs/MesonGeneratorRunner.md

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:

text

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:

text

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.

File: docs/ThrowTheSwitchCodingStandard.md

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.

;)

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.

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

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™.

When naming things, we follow this hierarchy, the first being the most important to us (but we do all four when possible):

Readable
Descriptive
Consistent
Memorable

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).

Descriptive

We like descriptive names for things, especially functions and variables.
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:

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.

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.

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'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++

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.

if (stuff_happened)
    {
        do_something();
    }

Case in C/C++

Files - all lower case with underscores.
Variables - all lower case with underscores
Macros - all caps with underscores.
Typedefs - all caps with underscores. (also ends with _T).
Functions - camel cased. Usually named ModuleName_FuncName
Constants and Globals - camel cased.

Braces in C/C++

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.

while (blah)
    {
        //Like so. Even if only one line, we use braces.
    }

Comments in C/C++

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!

Whitespace in Ruby

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 in Ruby

Files - all lower case with underscores.
Variables - all lower case with underscores
Classes, Modules, etc - Camel cased.
Functions - all lower case with underscores
Constants - all upper case with underscores

Documentation

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

File: docs/UnityAssertionsReference.md

Unity Assertions Reference

Background and Overview
Assertion Conventions and Configurations
The Assertions in All Their Blessed Glory
Advanced Asserting: Details On Tricky Assertions
1. How do the EQUAL assertions work for FLOAT and DOUBLE?
2. How do we deal with targets with non-standard int sizes?

Background and Overview

Super Condensed Version

An assertion establishes truth (i.e. boolean True) for a single condition.
Upon boolean False, an assertion stops execution and reports the failure.
Unity is mainly a rich collection of assertions and the support to gather up
and easily execute those assertions.
The structure of Unity allows you to easily separate test assertions from
source code in, well, test code.
Unity’s assertions:
- Come in many, many flavors to handle different C types and assertion cases.
- Use context to provide detailed and helpful failure messages.
- Document types, expected values, and basic behavior in your source code for
  free.

Unity Is Several Things But Mainly It’s Assertions

One way to think of Unity is simply as a rich collection of assertions you can
use to establish whether your source code behaves the way you think it does.
Unity provides a framework to easily organize and execute those assertions in
test code separate from your source code.

What’s an Assertion?

At their core, assertions are an establishment of truth - boolean truth. Was this
thing equal to that thing? Does that code doohickey have such-and-such property
or not? You get the idea. Assertions are executable code. Static analysis is a
valuable approach to improving code quality, but it is not executing your code
in the way an assertion can. A failing assertion stops execution and reports an
error through some appropriate I/O channel (e.g. stdout, GUI, output file,
blinky light).

Fundamentally, for dynamic verification all you need is a single assertion
mechanism. In fact, that’s what the assert() macro in C’s standard library
is for. So why not just use it? Well, we can do far better in the reporting
department. C’s assert() is pretty dumb as-is and is particularly poor for
handling common data types like arrays, structs, etc. And, without some other
support, it’s far too tempting to litter source code with C’s assert()’s. It’s
generally much cleaner, manageable, and more useful to separate test and source
code in the way Unity facilitates.

Unity’s Assertions: Helpful Messages _and_ Free Source Code Documentation

Asserting a simple truth condition is valuable, but using the context of the
assertion is even more valuable. For instance, if you know you’re comparing bit
flags and not just integers, then why not use that context to give explicit,
readable, bit-level feedback when an assertion fails?

That’s what Unity’s collection of assertions do - capture context to give you
helpful, meaningful assertion failure messages. In fact, the assertions
themselves also serve as executable documentation about types and values in your
source code. So long as your tests remain current with your source and all those
tests pass, you have a detailed, up-to-date view of the intent and mechanisms in
your source code. And due to a wondrous mystery, well-tested code usually tends
to be well designed code.

Assertion Conventions and Configurations

Naming and Parameter Conventions

The convention of assertion parameters generally follows this order:

TEST_ASSERT_X( {modifiers}, {expected}, actual, {size/count} )

The very simplest assertion possible uses only a single actual parameter (e.g.
a simple null check).

Actual is the value being tested and unlike the other parameters in an
assertion construction is the only parameter present in all assertion variants.
Modifiers are masks, ranges, bit flag specifiers, floating point deltas.
Expected is your expected value (duh) to compare to an actual value; it’s
marked as an optional parameter because some assertions only need a single
actual parameter (e.g. null check).
Size/count refers to string lengths, number of array elements, etc.

Many of Unity’s assertions are clear duplications in that the same data type
is handled by several assertions. The differences among these are in how failure
messages are presented. For instance, a _HEX variant of an assertion prints
the expected and actual values of that assertion formatted as hexadecimal.

TEST_ASSERT_X_MESSAGE Variants

All assertions are complemented with a variant that includes a simple string
message as a final parameter. The string you specify is appended to an assertion
failure message in Unity output.

For brevity, the assertion variants with a message parameter are not listed
below. Just tack on _MESSAGE as the final component to any assertion name in
the reference list below and add a string as the final parameter.

Example:

TEST_ASSERT_X( {modifiers}, {expected}, actual, {size/count} )

becomes messageified like thus…

TEST_ASSERT_X_MESSAGE( {modifiers}, {expected}, actual, {size/count}, message )

Notes:

The _MESSAGE variants intentionally do not support printf style formatting
since many embedded projects don’t support or avoid printf for various reasons.
It is possible to use sprintf before the assertion to assemble a complex fail
message, if necessary.
If you want to output a counter value within an assertion fail message (e.g. from
a loop) , building up an array of results and then using one of the _ARRAY
assertions (see below) might be a handy alternative to sprintf.

TEST_ASSERT_X_ARRAY Variants

Unity provides a collection of assertions for arrays containing a variety of
types. These are documented in the Array section below. These are almost on par
with the _MESSAGEvariants of Unity’s Asserts in that for pretty much any Unity
type assertion you can tack on _ARRAY and run assertions on an entire block of
memory.

TEST_ASSERT_EQUAL_TYPEX_ARRAY( expected, actual, {size/count} )

Expected is an array itself.
Size/count is one or two parameters necessary to establish the number of array
elements and perhaps the length of elements within the array.

Notes:

The _MESSAGE variant convention still applies here to array assertions. The
_MESSAGE variants of the _ARRAY assertions have names ending with
_ARRAY_MESSAGE.
Assertions for handling arrays of floating point values are grouped with float
and double assertions (see immediately following section).

TEST_ASSERT_EACH_EQUAL_X Variants

Unity provides a collection of assertions for arrays containing a variety of
types which can be compared to a single value as well. These are documented in
the Each Equal section below. these are almost on par with the _MESSAGE
variants of Unity’s Asserts in that for pretty much any Unity type assertion you
can inject _EACH_EQUAL and run assertions on an entire block of memory.

TEST_ASSERT_EACH_EQUAL_TYPEX( expected, actual, {size/count} )

Expected is a single value to compare to.
Actual is an array where each element will be compared to the expected value.
Size/count is one of two parameters necessary to establish the number of array
elements and perhaps the length of elements within the array.

Notes:

The _MESSAGE variant convention still applies here to Each Equal assertions.
Assertions for handling Each Equal of floating point values are grouped with
float and double assertions (see immediately following section).

Configuration

Floating Point Support Is Optional

Support for floating point types is configurable. That is, by defining the
appropriate preprocessor symbols, floats and doubles can be individually enabled
or disabled in Unity code. This is useful for embedded targets with no floating
point math support (i.e. Unity compiles free of errors for fixed point only
platforms). See Unity documentation for specifics.

Maximum Data Type Width Is Configurable

Not all targets support 64 bit wide types or even 32 bit wide types. Define the
appropriate preprocessor symbols and Unity will omit all operations from
compilation that exceed the maximum width of your target. See Unity
documentation for specifics.

The Assertions in All Their Blessed Glory

Basic Fail, Pass and Ignore

`TEST_FAIL()`

`TEST_FAIL_MESSAGE("message")`

This fella is most often used in special conditions where your test code is
performing logic beyond a simple assertion. That is, in practice, TEST_FAIL()
will always be found inside a conditional code block.

Examples:

Executing a state machine multiple times that increments a counter your test
code then verifies as a final step.
Triggering an exception and verifying it (as in Try / Catch / Throw - see the
CException project).

`TEST_PASS()`

`TEST_PASS_MESSAGE("message")`

This will abort the remainder of the test, but count the test as a pass. Under
normal circumstances, it is not necessary to include this macro in your tests…
a lack of failure will automatically be counted as a PASS. It is occasionally
useful for tests with #ifdefs and such.

`TEST_IGNORE()`

`TEST_IGNORE_MESSAGE("message")`

Marks a test case (i.e. function meant to contain test assertions) as ignored.
Usually this is employed as a breadcrumb to come back and implement a test case.
An ignored test case has effects if other assertions are in the enclosing test
case (see Unity documentation for more).

`TEST_MESSAGE(message)`

This can be useful for outputting INFO messages into the Unity output stream
without actually ending the test. Like pass and fail messages, it will be output
with the filename and line number.

Boolean

`TEST_ASSERT (condition)`

`TEST_ASSERT_TRUE (condition)`

`TEST_ASSERT_FALSE (condition)`

`TEST_ASSERT_UNLESS (condition)`

A simple wording variation on TEST_ASSERT_FALSE.The semantics of
TEST_ASSERT_UNLESS aid readability in certain test constructions or
conditional statements.

`TEST_ASSERT_NULL (pointer)`

`TEST_ASSERT_NOT_NULL (pointer)`

Verify if a pointer is or is not NULL.

`TEST_ASSERT_EMPTY (pointer)`

`TEST_ASSERT_NOT_EMPTY (pointer)`

Verify if the first element dereferenced from a pointer is or is not zero. This
is particularly useful for checking for empty (or non-empty) null-terminated
C strings, but can be just as easily used for other null-terminated arrays.

Signed and Unsigned Integers (of all sizes)

Large integer sizes can be disabled for build targets that do not support them.
For example, if your target only supports up to 16 bit types, by defining the
appropriate symbols Unity can be configured to omit 32 and 64 bit operations
that would break compilation (see Unity documentation for more). Refer to
Advanced Asserting later in this document for advice on dealing with other word
sizes.

`TEST_ASSERT_EQUAL_INT (expected, actual)`

`TEST_ASSERT_EQUAL_INT8 (expected, actual)`

`TEST_ASSERT_EQUAL_INT16 (expected, actual)`

`TEST_ASSERT_EQUAL_INT32 (expected, actual)`

`TEST_ASSERT_EQUAL_INT64 (expected, actual)`

`TEST_ASSERT_EQUAL_UINT (expected, actual)`

`TEST_ASSERT_EQUAL_UINT8 (expected, actual)`

`TEST_ASSERT_EQUAL_UINT16 (expected, actual)`

`TEST_ASSERT_EQUAL_UINT32 (expected, actual)`

`TEST_ASSERT_EQUAL_UINT64 (expected, actual)`

Unsigned Integers (of all sizes) in Hexadecimal

All _HEX assertions are identical in function to unsigned integer assertions
but produce failure messages with the expected and actual values formatted
in hexadecimal. Unity output is big endian.

`TEST_ASSERT_EQUAL_HEX (expected, actual)`

`TEST_ASSERT_EQUAL_HEX8 (expected, actual)`

`TEST_ASSERT_EQUAL_HEX16 (expected, actual)`

`TEST_ASSERT_EQUAL_HEX32 (expected, actual)`

`TEST_ASSERT_EQUAL_HEX64 (expected, actual)`

Characters

While you can use the 8-bit integer assertions to compare char, another option is
to use this specialized assertion which will show printable characters as printables,
otherwise showing the HEX escape code for the characters.

`TEST_ASSERT_EQUAL_CHAR (expected, actual)`

Masked and Bit-level Assertions

Masked and bit-level assertions produce output formatted in hexadecimal. Unity
output is big endian.

`TEST_ASSERT_BITS (mask, expected, actual)`

Only compares the masked (i.e. high) bits of expected and actual parameters.

`TEST_ASSERT_BITS_HIGH (mask, actual)`

Asserts the masked bits of the actual parameter are high.

`TEST_ASSERT_BITS_LOW (mask, actual)`

Asserts the masked bits of the actual parameter are low.

`TEST_ASSERT_BIT_HIGH (bit, actual)`

Asserts the specified bit of the actual parameter is high.

`TEST_ASSERT_BIT_LOW (bit, actual)`

Asserts the specified bit of the actual parameter is low.

Integer Less Than / Greater Than

These assertions verify that the actual parameter is less than or greater
than threshold (exclusive). For example, if the threshold value is 0 for the
greater than assertion will fail if it is 0 or less. There are assertions for
all the various sizes of ints, as for the equality assertions. Some examples:

`TEST_ASSERT_GREATER_THAN_INT8 (threshold, actual)`

`TEST_ASSERT_GREATER_OR_EQUAL_INT16 (threshold, actual)`

`TEST_ASSERT_LESS_THAN_INT32 (threshold, actual)`

`TEST_ASSERT_LESS_OR_EQUAL_UINT (threshold, actual)`

`TEST_ASSERT_NOT_EQUAL_UINT8 (threshold, actual)`

Integer Ranges (of all sizes)

These assertions verify that the expected parameter is within +/- delta
(inclusive) of the actual parameter. For example, if the expected value is 10
and the delta is 3 then the assertion will fail for any value outside the range
of 7 - 13.

`TEST_ASSERT_INT_WITHIN (delta, expected, actual)`

`TEST_ASSERT_INT8_WITHIN (delta, expected, actual)`

`TEST_ASSERT_INT16_WITHIN (delta, expected, actual)`

`TEST_ASSERT_INT32_WITHIN (delta, expected, actual)`

`TEST_ASSERT_INT64_WITHIN (delta, expected, actual)`

`TEST_ASSERT_UINT_WITHIN (delta, expected, actual)`

`TEST_ASSERT_UINT8_WITHIN (delta, expected, actual)`

`TEST_ASSERT_UINT16_WITHIN (delta, expected, actual)`

`TEST_ASSERT_UINT32_WITHIN (delta, expected, actual)`

`TEST_ASSERT_UINT64_WITHIN (delta, expected, actual)`

`TEST_ASSERT_HEX_WITHIN (delta, expected, actual)`

`TEST_ASSERT_HEX8_WITHIN (delta, expected, actual)`

`TEST_ASSERT_HEX16_WITHIN (delta, expected, actual)`

`TEST_ASSERT_HEX32_WITHIN (delta, expected, actual)`

`TEST_ASSERT_HEX64_WITHIN (delta, expected, actual)`

`TEST_ASSERT_CHAR_WITHIN (delta, expected, actual)`

Structs and Strings

`TEST_ASSERT_EQUAL_PTR (expected, actual)`

Asserts that the pointers point to the same memory location.

`TEST_ASSERT_NOT_EQUAL_PTR (expected, actual)`

Asserts that the pointers DO NOT point to the same memory location. Two NULL
pointers are considered equal and will cause this assertion to fail. A NULL
pointer and a non-NULL pointer are considered not equal and will pass.

`TEST_ASSERT_EQUAL_STRING (expected, actual)`

Asserts that the null terminated (’\0’) strings are identical. If strings are
of different lengths or any portion of the strings before their terminators
differ, the assertion fails. Two NULL strings (i.e. zero length) are considered
equivalent.

`TEST_ASSERT_NOT_EQUAL_STRING (expected, actual)`

Asserts that the null terminated (’\0’) strings are NOT identical. The
assertion passes if the strings differ in length or content at any point before
their null terminators. A NULL pointer and a non-NULL string are considered not
equal and will pass. Two NULL pointers are considered equal and will fail.

`TEST_ASSERT_EQUAL_STRING_LEN (expected, actual, len)`

Asserts that the null terminated (’\0’) strings are identical up to the specified length.
It checks only the first len characters, not the entire string.

`TEST_ASSERT_NOT_EQUAL_STRING_LEN (expected, actual, len)`

Asserts that the null terminated (’\0’) strings are NOT identical within the
first len characters. The assertion passes if the strings differ at any
position within the specified length. A NULL pointer and a non-NULL string are
considered not equal and will pass. Two NULL pointers are considered equal and
will fail. Specifying a len of zero is considered pointless and will fail.

`TEST_ASSERT_EQUAL_MEMORY (expected, actual, len)`

Asserts that the contents of the memory specified by the expected and actual
pointers is identical. The size of the memory blocks in bytes is specified by
the len parameter.

`TEST_ASSERT_NOT_EQUAL_MEMORY (expected, actual, len)`

Asserts that the contents of the memory specified by the expected and actual
pointers is NOT identical within the first len bytes. The assertion passes if
any byte differs within that range. A NULL pointer and a non-NULL pointer are
considered not equal and will pass. Two NULL pointers (or the same pointer) are
considered equal and will fail. Specifying a len of zero is considered
pointless and will fail.

Arrays

expected and actual parameters are both arrays. num_elements specifies the
number of elements in the arrays to compare.

_HEX assertions produce failure messages with expected and actual array
contents formatted in hexadecimal.

For array of strings comparison behavior, see comments for
TEST_ASSERT_EQUAL_STRING in the preceding section.

Assertions fail upon the first element in the compared arrays found not to
match. Failure messages specify the array index of the failed comparison.

`TEST_ASSERT_EQUAL_INT_ARRAY (expected, actual, num_elements)`

`TEST_ASSERT_EQUAL_INT8_ARRAY (expected, actual, num_elements)`

`TEST_ASSERT_EQUAL_INT16_ARRAY (expected, actual, num_elements)`

`TEST_ASSERT_EQUAL_INT32_ARRAY (expected, actual, num_elements)`

`TEST_ASSERT_EQUAL_INT64_ARRAY (expected, actual, num_elements)`

`TEST_ASSERT_EQUAL_UINT_ARRAY (expected, actual, num_elements)`

`TEST_ASSERT_EQUAL_UINT8_ARRAY (expected, actual, num_elements)`

`TEST_ASSERT_EQUAL_UINT16_ARRAY (expected, actual, num_elements)`

`TEST_ASSERT_EQUAL_UINT32_ARRAY (expected, actual, num_elements)`

`TEST_ASSERT_EQUAL_UINT64_ARRAY (expected, actual, num_elements)`

`TEST_ASSERT_EQUAL_HEX_ARRAY (expected, actual, num_elements)`

`TEST_ASSERT_EQUAL_HEX8_ARRAY (expected, actual, num_elements)`

`TEST_ASSERT_EQUAL_HEX16_ARRAY (expected, actual, num_elements)`

`TEST_ASSERT_EQUAL_HEX32_ARRAY (expected, actual, num_elements)`

`TEST_ASSERT_EQUAL_HEX64_ARRAY (expected, actual, num_elements)`

`TEST_ASSERT_EQUAL_CHAR_ARRAY (expected, actual, num_elements)`

`TEST_ASSERT_EQUAL_PTR_ARRAY (expected, actual, num_elements)`

`TEST_ASSERT_EQUAL_STRING_ARRAY (expected, actual, num_elements)`

`TEST_ASSERT_EQUAL_MEMORY_ARRAY (expected, actual, len, num_elements)`

len is the memory in bytes to be compared at each array element.

Integer Array Ranges (of all sizes)

These assertions verify that the expected array parameter is within +/- delta
(inclusive) of the actual array parameter. For example, if the expected value is
[10, 12] and the delta is 3 then the assertion will fail for any value
outside the range of [7 - 13, 9 - 15].

`TEST_ASSERT_INT_ARRAY_WITHIN (delta, expected, actual, num_elements)`

`TEST_ASSERT_INT8_ARRAY_WITHIN (delta, expected, actual, num_elements)`

`TEST_ASSERT_INT16_ARRAY_WITHIN (delta, expected, actual, num_elements)`

`TEST_ASSERT_INT32_ARRAY_WITHIN (delta, expected, actual, num_elements)`

`TEST_ASSERT_INT64_ARRAY_WITHIN (delta, expected, actual, num_elements)`

`TEST_ASSERT_UINT_ARRAY_WITHIN (delta, expected, actual, num_elements)`

`TEST_ASSERT_UINT8_ARRAY_WITHIN (delta, expected, actual, num_elements)`

`TEST_ASSERT_UINT16_ARRAY_WITHIN (delta, expected, actual, num_elements)`

`TEST_ASSERT_UINT32_ARRAY_WITHIN (delta, expected, actual, num_elements)`

`TEST_ASSERT_UINT64_ARRAY_WITHIN (delta, expected, actual, num_elements)`

`TEST_ASSERT_HEX_ARRAY_WITHIN (delta, expected, actual, num_elements)`

`TEST_ASSERT_HEX8_ARRAY_WITHIN (delta, expected, actual, num_elements)`

`TEST_ASSERT_HEX16_ARRAY_WITHIN (delta, expected, actual, num_elements)`

`TEST_ASSERT_HEX32_ARRAY_WITHIN (delta, expected, actual, num_elements)`

`TEST_ASSERT_HEX64_ARRAY_WITHIN (delta, expected, actual, num_elements)`

`TEST_ASSERT_CHAR_ARRAY_WITHIN (delta, expected, actual, num_elements)`

Each Equal (Arrays to Single Value)

expected are single values and actual are arrays. num_elements specifies
the number of elements in the arrays to compare.

_HEX assertions produce failure messages with expected and actual array
contents formatted in hexadecimal.

Assertions fail upon the first element in the compared arrays found not to
match. Failure messages specify the array index of the failed comparison.

`TEST_ASSERT_EACH_EQUAL_INT (expected, actual, num_elements)`

`TEST_ASSERT_EACH_EQUAL_INT8 (expected, actual, num_elements)`

`TEST_ASSERT_EACH_EQUAL_INT16 (expected, actual, num_elements)`

`TEST_ASSERT_EACH_EQUAL_INT32 (expected, actual, num_elements)`

`TEST_ASSERT_EACH_EQUAL_INT64 (expected, actual, num_elements)`

`TEST_ASSERT_EACH_EQUAL_UINT (expected, actual, num_elements)`

`TEST_ASSERT_EACH_EQUAL_UINT8 (expected, actual, num_elements)`

`TEST_ASSERT_EACH_EQUAL_UINT16 (expected, actual, num_elements)`

`TEST_ASSERT_EACH_EQUAL_UINT32 (expected, actual, num_elements)`

`TEST_ASSERT_EACH_EQUAL_UINT64 (expected, actual, num_elements)`

`TEST_ASSERT_EACH_EQUAL_HEX (expected, actual, num_elements)`

`TEST_ASSERT_EACH_EQUAL_HEX8 (expected, actual, num_elements)`

`TEST_ASSERT_EACH_EQUAL_HEX16 (expected, actual, num_elements)`

`TEST_ASSERT_EACH_EQUAL_HEX32 (expected, actual, num_elements)`

`TEST_ASSERT_EACH_EQUAL_HEX64 (expected, actual, num_elements)`

`TEST_ASSERT_EACH_EQUAL_CHAR (expected, actual, num_elements)`

`TEST_ASSERT_EACH_EQUAL_PTR (expected, actual, num_elements)`

`TEST_ASSERT_EACH_EQUAL_STRING (expected, actual, num_elements)`

`TEST_ASSERT_EACH_EQUAL_MEMORY (expected, actual, len, num_elements)`

len is the memory in bytes to be compared at each array element.

Floating Point (If enabled)

`TEST_ASSERT_FLOAT_WITHIN (delta, expected, actual)`

Asserts that the actual value is within +/- delta of the expected value.
The nature of floating point representation is such that exact evaluations of
equality are not guaranteed.

`TEST_ASSERT_FLOAT_NOT_WITHIN (delta, expected, actual)`

Asserts that the actual value is NOT within +/- delta of the expected value.

`TEST_ASSERT_EQUAL_FLOAT (expected, actual)`

Asserts that the actual value is “close enough to be considered equal” to the
expected value. If you are curious about the details, refer to the Advanced
Asserting section for more details on this. Omitting a user-specified delta in a
floating point assertion is both a shorthand convenience and a requirement of
code generation conventions for CMock.

`TEST_ASSERT_NOT_EQUAL_FLOAT (expected, actual)`

Asserts that the actual value is NOT “close enough to be considered equal” to the
expected value.

`TEST_ASSERT_FLOAT_ARRAY_WITHIN (delta, expected, actual, num_elements)`

See Array assertion section for details. Note that individual array element
uses user-provided delta plus default comparison delta for checking
and is based on TEST_ASSERT_FLOAT_WITHIN comparison.

`TEST_ASSERT_EQUAL_FLOAT_ARRAY (expected, actual, num_elements)`

See Array assertion section for details. Note that individual array element
float comparisons are executed using TEST_ASSERT_EQUAL_FLOAT. That is, user
specified delta comparison values requires a custom-implemented floating point
array assertion.

`TEST_ASSERT_LESS_THAN_FLOAT (threshold, actual)`

Asserts that the actual parameter is less than threshold (exclusive).
For example, if the threshold value is 1.0f, the assertion will fail if it is
greater than 1.0f.

`TEST_ASSERT_GREATER_THAN_FLOAT (threshold, actual)`

Asserts that the actual parameter is greater than threshold (exclusive).
For example, if the threshold value is 1.0f, the assertion will fail if it is
less than 1.0f.

`TEST_ASSERT_LESS_OR_EQUAL_FLOAT (threshold, actual)`

Asserts that the actual parameter is less than or equal to threshold.
The rules for equality are the same as for TEST_ASSERT_EQUAL_FLOAT.

`TEST_ASSERT_GREATER_OR_EQUAL_FLOAT (threshold, actual)`

Asserts that the actual parameter is greater than threshold.
The rules for equality are the same as for TEST_ASSERT_EQUAL_FLOAT.

`TEST_ASSERT_FLOAT_IS_INF (actual)`

Asserts that actual parameter is equivalent to positive infinity floating
point representation.

`TEST_ASSERT_FLOAT_IS_NEG_INF (actual)`

Asserts that actual parameter is equivalent to negative infinity floating
point representation.

`TEST_ASSERT_FLOAT_IS_NAN (actual)`

Asserts that actual parameter is a Not A Number floating point representation.

`TEST_ASSERT_FLOAT_IS_DETERMINATE (actual)`

Asserts that actual parameter is a floating point representation usable for
mathematical operations. That is, the actual parameter is neither positive
infinity nor negative infinity nor Not A Number floating point representations.

`TEST_ASSERT_FLOAT_IS_NOT_INF (actual)`

Asserts that actual parameter is a value other than positive infinity floating
point representation.

`TEST_ASSERT_FLOAT_IS_NOT_NEG_INF (actual)`

Asserts that actual parameter is a value other than negative infinity floating
point representation.

`TEST_ASSERT_FLOAT_IS_NOT_NAN (actual)`

Asserts that actual parameter is a value other than Not A Number floating
point representation.

`TEST_ASSERT_FLOAT_IS_NOT_DETERMINATE (actual)`

Asserts that actual parameter is not usable for mathematical operations. That
is, the actual parameter is either positive infinity or negative infinity or
Not A Number floating point representations.

Double (If enabled)

`TEST_ASSERT_DOUBLE_WITHIN (delta, expected, actual)`

Asserts that the actual value is within +/- delta of the expected value.
The nature of floating point representation is such that exact evaluations of
equality are not guaranteed.

`TEST_ASSERT_DOUBLE_NOT_WITHIN (delta, expected, actual)`

Asserts that the actual value is NOT within +/- delta of the expected value.

`TEST_ASSERT_EQUAL_DOUBLE (expected, actual)`

Asserts that the actual value is “close enough to be considered equal” to the
expected value. If you are curious about the details, refer to the Advanced
Asserting section for more details. Omitting a user-specified delta in a
floating point assertion is both a shorthand convenience and a requirement of
code generation conventions for CMock.

`TEST_ASSERT_NOT_EQUAL_DOUBLE (expected, actual)`

Asserts that the actual value is NOT “close enough to be considered equal” to the
expected value.

`TEST_ASSERT_DOUBLE_ARRAY_WITHIN (delta, expected, actual, num_elements)`

See Array assertion section for details. Note that individual array element
uses user-provided delta plus default comparison delta for checking
and is based on TEST_ASSERT_DOUBLE_WITHIN comparison.

`TEST_ASSERT_EQUAL_DOUBLE_ARRAY (expected, actual, num_elements)`

See Array assertion section for details. Note that individual array element
double comparisons are executed using TEST_ASSERT_EQUAL_DOUBLE. That is, user
specified delta comparison values requires a custom implemented double array
assertion.

`TEST_ASSERT_LESS_THAN_DOUBLE (threshold, actual)`

Asserts that the actual parameter is less than threshold (exclusive).
For example, if the threshold value is 1.0, the assertion will fail if it is
greater than 1.0.

`TEST_ASSERT_LESS_OR_EQUAL_DOUBLE (threshold, actual)`

Asserts that the actual parameter is less than or equal to threshold.
The rules for equality are the same as for TEST_ASSERT_EQUAL_DOUBLE.

`TEST_ASSERT_GREATER_THAN_DOUBLE (threshold, actual)`

Asserts that the actual parameter is greater than threshold (exclusive).
For example, if the threshold value is 1.0, the assertion will fail if it is
less than 1.0.

`TEST_ASSERT_GREATER_OR_EQUAL_DOUBLE (threshold, actual)`

Asserts that the actual parameter is greater than or equal to threshold.
The rules for equality are the same as for TEST_ASSERT_EQUAL_DOUBLE.

`TEST_ASSERT_DOUBLE_IS_INF (actual)`

Asserts that actual parameter is equivalent to positive infinity floating
point representation.

`TEST_ASSERT_DOUBLE_IS_NEG_INF (actual)`

Asserts that actual parameter is equivalent to negative infinity floating point
representation.

`TEST_ASSERT_DOUBLE_IS_NAN (actual)`

Asserts that actual parameter is a Not A Number floating point representation.

`TEST_ASSERT_DOUBLE_IS_DETERMINATE (actual)`

`TEST_ASSERT_DOUBLE_IS_NOT_INF (actual)`

Asserts that actual parameter is a value other than positive infinity floating
point representation.

`TEST_ASSERT_DOUBLE_IS_NOT_NEG_INF (actual)`

Asserts that actual parameter is a value other than negative infinity floating
point representation.

`TEST_ASSERT_DOUBLE_IS_NOT_NAN (actual)`

Asserts that actual parameter is a value other than Not A Number floating
point representation.

`TEST_ASSERT_DOUBLE_IS_NOT_DETERMINATE (actual)`

Advanced Asserting: Details On Tricky Assertions

This section helps you understand how to deal with some of the trickier
assertion situations you may run into. It will give you a glimpse into some of
the under-the-hood details of Unity’s assertion mechanisms. If you’re one of
those people who likes to know what is going on in the background, read on. If
not, feel free to ignore the rest of this document until you need it.

How do the EQUAL assertions work for FLOAT and DOUBLE?

As you may know, directly checking for equality between a pair of floats or a
pair of doubles is sloppy at best and an outright no-no at worst. Floating point
values can often be represented in multiple ways, particularly after a series of
operations on a value. Initializing a variable to the value of 2.0 is likely to
result in a floating point representation of 2 x 20,but a series of
mathematical operations might result in a representation of 8 x 2-2
that also evaluates to a value of 2. At some point repeated operations cause
equality checks to fail.

So Unity doesn’t do direct floating point comparisons for equality. Instead, it
checks if two floating point values are “really close.” If you leave Unity
running with defaults, “really close” means “within a significant bit or two.”
Under the hood, TEST_ASSERT_EQUAL_FLOAT is really TEST_ASSERT_FLOAT_WITHIN
with the delta parameter calculated on the fly. For single precision, delta is
the expected value multiplied by 0.00001, producing a very small proportional
range around the expected value.

If you are expecting a value of 20,000.0 the delta is calculated to be 0.2. So
any value between 19,999.8 and 20,000.2 will satisfy the equality check. This
works out to be roughly a single bit of range for a single-precision number, and
that’s just about as tight a tolerance as you can reasonably get from a floating
point value.

So what happens when it’s zero? Zero - even more than other floating point
values - can be represented many different ways. It doesn’t matter if you have
0x20 or 0x263. It’s still zero, right? Luckily, if you subtract these
values from each other, they will always produce a difference of zero, which
will still fall between 0 plus or minus a delta of 0. So it still works!

Double precision floating point numbers use a much smaller multiplier, again
approximating a single bit of error.

If you don’t like these ranges and you want to make your floating point equality
assertions less strict, you can change these multipliers to whatever you like by
defining UNITY_FLOAT_PRECISION and UNITY_DOUBLE_PRECISION. See Unity
documentation for more.

How do we deal with targets with non-standard int sizes?

It’s “fun” that C is a standard where something as fundamental as an integer
varies by target. According to the C standard, an int is to be the target’s
natural register size, and it should be at least 16-bits and a multiple of a
byte. It also guarantees an order of sizes:

char <= short <= int <= long <= long long

Most often, int is 32-bits. In many cases in the embedded world, int is
16-bits. There are rare microcontrollers out there that have 24-bit integers,
and this remains perfectly standard C.

To make things even more interesting, there are compilers and targets out there
that have a hard choice to make. What if their natural register size is 10-bits
or 12-bits? Clearly they can’t fulfill both the requirement to be at least
16-bits AND the requirement to match the natural register size. In these
situations, they often choose the natural register size, leaving us with
something like this:

char (8 bit) <= short (12 bit) <= int (12 bit) <= long (16 bit)

Um… yikes. It’s obviously breaking a rule or two… but they had to break SOME
rules, so they made a choice.

When the C99 standard rolled around, it introduced alternate standard-size types.
It also introduced macros for pulling in MIN/MAX values for your integer types.
It’s glorious! Unfortunately, many embedded compilers can’t be relied upon to
use the C99 types (Sometimes because they have weird register sizes as described
above. Sometimes because they don’t feel like it?).

A goal of Unity from the beginning was to support every combination of
microcontroller or microprocessor and C compiler. Over time, we’ve gotten really
close to this. There are a few tricks that you should be aware of, though, if
you’re going to do this effectively on some of these more idiosyncratic targets.

First, when setting up Unity for a new target, you’re going to want to pay
special attention to the macros for automatically detecting types
(where available) or manually configuring them yourself. You can get information
on both of these in Unity’s documentation.

What about the times where you suddenly need to deal with something odd, like a
24-bit int? The simplest solution is to use the next size up. If you have a
24-bit int, configure Unity to use 32-bit integers. If you have a 12-bit
int, configure Unity to use 16 bits. There are two ways this is going to
affect you:

When Unity displays errors for you, it’s going to pad the upper unused bits
with zeros.
You’re going to have to be careful of assertions that perform signed
operations, particularly TEST_ASSERT_INT_WITHIN. Such assertions might wrap
your int in the wrong place, and you could experience false failures. You can
always back down to a simple TEST_ASSERT and do the operations yourself.

Find The Latest of This And More at ThrowTheSwitch.org

File: docs/UnityChangeLog.md

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.7.0 (July 2026)

New Features:

Add option to test runner generator to shuffle test order
Optional new detail "stack" report on failures

Significant Bugfixes:

Default gcc and clang targets can run on non-x86 without modification (#778)
Backslashes handled properly in generator (#837)
Floating point avoids use of == and != always (#819)
Added not equal for string, memory, and pointer handling (#811)
display of failures fixed on ARM processors, particularly with arrays (#807)
fixed each-equal assertion for memory (#797)
fix many warnings.
Test runner generator calls custom suite teardown when begin/end calls are omitted. @94xhn

Other:

Clean up core targets for simpler use on host environments
Documentation improvements

Major Code/Doc Contributors

These individuals contributed significant features, bugfixes, and improvements.

Mark VanderVoord
Ross Smyth
burakutkuc
ml-physec
Roland Stahn
aditya
Dariqq
James Browning
savashn

Also, thanks for your contributions!

Artem Sharipov, Christer Fletcher, Costas Akrivoulis, Dominik Loidolt, Ivan Kravets, Jacques Boivin, James Raphael Tiovalen, Joshua Stone, Lucas Saavedra Vaz, Michael Dwan, Roland Marchand, yahyayozo

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

File: docs/UnityConfigurationGuide.md

Unity Configuration Guide

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.

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:

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

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

Example:

#define UNITY_EXCLUDE_STDINT_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.

Example:

#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.

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

Example:

#define UNITY_INT_WIDTH 16

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

Example:

#define UNITY_LONG_WIDTH 16

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

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:

// Choose on of these #defines to set your pointer width (if not autodetected)
//#define UNITY_POINTER_WIDTH 16
//#define UNITY_POINTER_WIDTH 32
#define UNITY_POINTER_WIDTH 64 // Set UNITY_POINTER_WIDTH to 64-bit

`UNITY_COMPARE_PTRS_ON_ZERO_ARRAY`

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_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:

#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.

`UNITY_INCLUDE_FLOAT`

`UNITY_EXCLUDE_FLOAT`

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

Example:

//what manner of strange processor is this?
#define UNITY_EXCLUDE_FLOAT
#define UNITY_INCLUDE_DOUBLE

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

Example:

#define UNITY_EXCLUDE_FLOAT_PRINT

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

Example:

#define UNITY_FLOAT_TYPE float16_t

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

Example:

#define UNITY_DOUBLE_TYPE long double

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

Example:

#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:

#define UNITY_IS_NAN(n) ((n != n) ? 1 : 0)

Miscellaneous

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

Example:

#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:

%d - signed value (decimal)
%i - same as %d
%u - unsigned value (decimal)
%f - float/Double (if float support is activated)
%g - same as %f
%b - binary prefixed with "0b"
%x - hexadecimal (upper case) prefixed with "0x"
%X - same as %x
%p - pointer (same as %x or %X)
%c - a single character
%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:

#define UNITY_INCLUDE_PRINT_FORMATTED

int a = 0xfab1;
TEST_PRINTF("Decimal   %d\n", -7);
TEST_PRINTF("Unsigned  %u\n", 987);
TEST_PRINTF("Float     %f\n", 3.1415926535897932384);
TEST_PRINTF("Binary    %b\n", 0xA);
TEST_PRINTF("Hex       %X\n", 0xFAB);
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("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.

`UNITY_OUTPUT_CHAR(a)`

`UNITY_OUTPUT_FLUSH()`

`UNITY_OUTPUT_START()`

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

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:

#include "RS232_header.h"
...
#define UNITY_OUTPUT_CHAR(a)    RS232_putc(a)
#define UNITY_OUTPUT_START()    RS232_config(115200,1,8,0)
#define UNITY_OUTPUT_FLUSH()    RS232_flush()
#define UNITY_OUTPUT_COMPLETE() RS232_close()

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_FOR_ECLIPSE`

`UNITY_OUTPUT_FOR_IAR_WORKBENCH`

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

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

Example:

#define UNITY_PTR_ATTRIBUTE __attribute__((far))
#define UNITY_PTR_ATTRIBUTE near

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

Example:

#define UNITY_PRINT_EOL() { UNITY_OUTPUT_CHAR('\r'); UNITY_OUTPUT_CHAR('\n'); }

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

Example:

#define UNITY_EXCLUDE_DETAILS

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

Example:

#define UNITY_PRINT_TEST_CONTEXT PrintIterationCount

extern int iteration_count;

void PrintIterationCount(void)
{
  UnityPrintFormatted("At iteration #%d: ", iteration_count);
}

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

Example:

#define UNITY_EXCLUDE_SETJMP

`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:

#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:

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:

#include "my_custom_test_handlers.h"

#define UNITY_TEST_PROTECT() 1
#define UNITY_TEST_ABORT()   custom_test_abort()

my_custom_test_handlers.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:

#define UNITY_OUTPUT_COLOR

`UNITY_INCLUDE_EXEC_TIME`

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.

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

`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:

#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.

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

A simple main function looks something like this:

int main(void) {
    UNITY_BEGIN();
    RUN_TEST(test_TheFirst);
    RUN_TEST(test_TheSecond);
    RUN_TEST(test_TheThird);
    return UNITY_END();
}

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.

`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:

#define RUN_TEST(testfunc) \
    UNITY_NEW_TEST(#testfunc) \
    if (TEST_PROTECT()) { \
        setUp(); \
        testfunc(); \
    } \
    if (TEST_PROTECT() && (!TEST_IS_IGNORED)) \
        tearDown(); \
    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.

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!

Find The Latest of This And More at ThrowTheSwitch.org

File: docs/UnityGettingStartedGuide.md

Unity - Getting Started

Welcome

Congratulations.
You're now the proud owner of your very own pile of bits!
What are you going to do with all these ones and zeros?
This document should be able to help you decide just that.

Unity is a unit test framework.
The goal has been to keep it small and functional.
The core Unity test framework is three files: a single C file and a couple header files.
These team up to provide functions and macros to make testing easier.

Unity was designed to be cross-platform.
It works hard to stick with C standards while still providing support for the many embedded C compilers that bend the rules.
Unity has been used with many compilers, including GCC, IAR, Clang, Green Hills, Microchip, and MS Visual Studio.
It's not much work to get it to work with a new target.

Overview of the Documents

Unity Assertions reference

This document will guide you through all the assertion options provided by Unity.
This is going to be your unit testing bread and butter.
You'll spend more time with assertions than any other part of Unity.

Unity Assertions Cheat Sheet

This document contains an abridged summary of the assertions described in the previous document.
It's perfect for printing and referencing while you familiarize yourself with Unity's options.

Unity Configuration Guide

This document is the one to reference when you are going to use Unity with a new target or compiler.
It'll guide you through the configuration options and will help you customize your testing experience to meet your needs.

Unity Helper Scripts

This document describes the helper scripts that are available for simplifying your testing workflow.
It describes the collection of optional Ruby scripts included in the auto directory of your Unity installation.
Neither Ruby nor these scripts are necessary for using Unity.
They are provided as a convenience for those who wish to use them.

Unity License

What's an open source project without a license file?
This brief document describes the terms you're agreeing to when you use this software.
Basically, we want it to be useful to you in whatever context you want to use it, but please don't blame us if you run into problems.

Overview of the Folders

If you have obtained Unity through Github or something similar, you might be surprised by just how much stuff you suddenly have staring you in the face.
Don't worry, Unity itself is very small.
The rest of it is just there to make your life easier.
You can ignore it or use it at your convenience.
Here's an overview of everything in the project.

src - This is the code you care about! This folder contains a C file and two header files.
These three files are Unity.
docs - You're reading this document, so it's possible you have found your way into this folder already.
This is where all the handy documentation can be found.
examples - This contains a few examples of using Unity.
extras - These are optional add ons to Unity that are not part of the core project.
If you've reached us through James Grenning's book, you're going to want to look here.
test - This is how Unity and its scripts are all tested.
If you're just using Unity, you'll likely never need to go in here.
If you are the lucky team member who gets to port Unity to a new toolchain, this is a good place to verify everything is configured properly.
auto - Here you will find helpful Ruby scripts for simplifying your test workflow.
They are purely optional and are not required to make use of Unity.

How to Create A Test File

Test files are C files.
Most often you will create a single test file for each C module that you want to test.
The test file should include unity.h and the header for your C module to be tested.

Next, a test file will include a setUp() and tearDown() function.
The setUp function can contain anything you would like to run before each test.
The tearDown function can contain anything you would like to run after each test.
Both functions accept no arguments and return nothing.
You may leave either or both of these blank if you have no need for them.

If you're using 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.

Finally, at the bottom of your test file, you will write a main() function.
This function will call UNITY_BEGIN(), then RUN_TEST for each test, and finally UNITY_END().
This is what will actually trigger each of those test functions to run, so it is important that each function gets its own RUN_TEST call.

Remembering to add each test to the main function can get to be tedious.
If you enjoy using helper scripts in your build process, you might consider making use of our handy generate_test_runner.rb script.
This will create the main function and all the calls for you, assuming that you have followed the suggested naming conventions.
In this case, there is no need for you to include the main function in your test file at all.

When you're done, your test file will look something like this:

#include "unity.h"
#include "file_to_test.h"

void setUp(void) {
    // set stuff up here
}

void tearDown(void) {
    // clean stuff up here
}

void test_function_should_doBlahAndBlah(void) {
    //test stuff
}

void test_function_should_doAlsoDoBlah(void) {
    //more test stuff
}

// not needed when using generate_test_runner.rb
int main(void) {
    UNITY_BEGIN();
    RUN_TEST(test_function_should_doBlahAndBlah);
    RUN_TEST(test_function_should_doAlsoDoBlah);
    return UNITY_END();
}

It's possible that you will need more customization than this, eventually.
For that sort of thing, you're going to want to look at the configuration guide.
This should be enough to get you going, though.

Running Test Functions

When writing your own main() functions, for a test-runner.
There are two ways to execute the test.

The classic variant

RUN_TEST(func, linenum)

Or its simpler replacement that starts at the beginning of the function.

RUN_TEST(func)

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.
This is useful when your test runners are automatically generated.

TEST_IGNORE()

Ignore this test and return immediately

TEST_IGNORE_MESSAGE (message)

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.

TEST_PROTECT()

Setup and Catch macro

TEST_ABORT()

Abort Test macro

Example:

main()
    {
        if (TEST_PROTECT())
        {
            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.

You have two really good options for toolchains.
Depending on where you're coming from, it might surprise you that neither of these options is running the unit tests on your hardware.
There are many reasons for this, but here's a short version:

On hardware, you have too many constraints (processing power, memory, etc),
On hardware, you don't have complete control over all registers,
On hardware, unit testing is more challenging,
Unit testing isn't System testing. Keep them separate.

Instead of running your tests on your actual hardware, most developers choose to develop them as native applications (using gcc or MSVC for example) or as applications running on a simulator.
Either is a good option.
Native apps have the advantages of being faster and easier to set up.
Simulator apps have the advantage of working with the same compiler as your target application.
The options for configuring these are discussed in the configuration guide.

To get either to work, you might need to make a few changes to the file containing your register set (discussed later).

In either case, a test is built by linking unity, the test file, and the C file(s) being tested.
These files create an executable which can be run as the test set for that module.
Then, this process is repeated for the next test file.
This flexibility of separating tests into individual executables allows us to much more thoroughly unit test our system and it keeps all the test code out of our final release!

Find The Latest of This And More at ThrowTheSwitch.org

File: docs/UnityHelperScriptsGuide.md

Unity Helper Scripts

With a Little Help From Our Friends

Sometimes what it takes to be a really efficient C programmer is a little non-C.
The Unity project includes a couple 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?

Well then we have the perfect script for you!

The generate_test_runner script processes a given test file and automatically creates a separate test runner file that includes ?main?to execute the test cases within the scanned test file.
All you do then is add the generated runner to your list of files to be compiled and linked, and presto you're done!

This script searches your test file for void function signatures having a function name beginning with "test" or "spec".
It treats each of these functions as a test case and builds up a test suite of them.
For example, the following includes three test cases:

void testVerifyThatUnityIsAwesomeAndWillMakeYourLifeEasier(void)
{
  ASSERT_TRUE(1);
}
void test_FunctionName_should_WorkProperlyAndReturn8(void) {
  ASSERT_EQUAL_INT(8, FunctionName());
}
void spec_Function_should_DoWhatItIsSupposedToDo(void) {
  ASSERT_NOT_NULL(Function(5));
}

You can run this script a couple of ways.
The first is from the command line:

shell

ruby generate_test_runner.rb TestFile.c NameOfRunner.c

Alternatively, if you include only the test file parameter, the script will copy the name of the test file and automatically append _Runner to the name of the generated file.
The example immediately below will create TestFile_Runner.c.

shell

ruby generate_test_runner.rb TestFile.c

You can also add a YAML file to configure extra options.
Conveniently, this YAML file is of the same format as that used by Unity and CMock.
So if you are using YAML files already, you can simply pass the very same file into the generator script.

shell

ruby generate_test_runner.rb TestFile.c my_config.yml

The contents of the YAML file my_config.yml could look something like the example below.
If you're wondering what some of these options do, you're going to love the next section of this document.

yaml

:unity:
  :includes:
    - stdio.h
    - microdefs.h
  :cexception: 1
  :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:

shell

ruby generate_test_runner.rb TestFile.c my_config.yml extras.h

Another option, particularly if you are already using Ruby to orchestrate your builds - or more likely the Ruby-based build tool Rake - is requiring this script directly.
Anything that you would have specified in a YAML file can be passed to the script as part of a hash.
Let's push the exact same requirement set as we did above but this time through Ruby code directly:

ruby

require "generate_test_runner.rb"
options = {
  :includes => ["stdio.h", "microdefs.h"],
  :cexception => 1,
  :suite_setup => "blah = malloc(1024);",
  :suite_teardown => "free(blah);"
}
UnityTestRunnerGenerator.new.run(testfile, runner_name, options)

If you have multiple files to generate in a build script (such as a Rakefile), you might want to instantiate a generator object with your options and call it to generate each runner afterwards.
Like this:

ruby

gen = UnityTestRunnerGenerator.new(options)
test_files.each do |f|
  gen.run(f, File.basename(f,'.c')+"Runner.c")
end

Options accepted by generate_test_runner.rb

The following options are available when executing generate_test_runner.
You may pass these as a Ruby hash directly or specify them in a YAML file, both of which are described above.
In the examples directory, Example 3's Rakefile demonstrates using a Ruby hash.

`:includes`

This option specifies an array of file names to be #include'd at the top of your runner C file.
You might use it to reference custom types or anything else universally needed in your generated runners.

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

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.

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.

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

`:plugins`

This option specifies an array of plugins to be used (of course, the array can contain only a single plugin).
This is your opportunity to enable support for CException support, which will add a check for unhandled exceptions in each test, reporting a failure if one is detected.
To enable this feature using Ruby:

ruby

:plugins => [ :cexception ]

Or as a yaml file:

yaml

:plugins:
  -:cexception

If you are using CMock, it is very likely that you are already passing an array of plugins to CMock.
You can just use the same array here.

This script will just ignore the plugins that don't require additional support.

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)'.

`: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)'.

`: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
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:

/* 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:

TEST_CASE(1, 2, 5)
TEST_CASE(10, 7, 20)

script will generate 2 test calls:

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:

[start, stop, step] is stop-inclusive format
<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:

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:

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 [, , ..., , ].

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:

TEST_MATRIX([3, 4, 7], [10, 8, 2, 1],[30u, 20.0f])

Tests execution output will be similar to that text:

text

/* Detailed source-code truncated for AI context efficiency. */

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:

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.

If you're interested in other (prettier?) output formats, check into the Ceedling build tool project that works with Unity and CMock and supports xunit-style xml as well as other goodies.

This script assumes the existence of files ending with the extensions .testpass and .testfail.
The contents of these files includes the test results summary corresponding to each test file executed with the extension set according to the presence or absence of failures for that test file.
The script searches a specified path for these files, opens each one it finds, parses the results, and aggregates and prints a summary.
Calling it from the command line looks like this:

shell

ruby unity_test_summary.rb build/test/

You can optionally specify a root path as well.
This is really helpful when you are using relative paths in your tools' setup, but you want to pull the summary into an IDE like Eclipse for clickable shortcuts.

shell

ruby unity_test_summary.rb build/test/ ~/projects/myproject/

Or, if you're more of a Windows sort of person:

shell

ruby unity_test_summary.rb build\test\ C:\projects\myproject\

When configured correctly, you'll see a final summary, like so:

shell

--------------------------
UNITY IGNORED TEST SUMMARY
--------------------------
blah.c:22:test_sandwiches_should_HaveBreadOnTwoSides:IGNORE

-------------------------
UNITY FAILED TEST SUMMARY
-------------------------
blah.c:87:test_sandwiches_should_HaveCondiments:FAIL:Expected 1 was 0
meh.c:38:test_soda_should_BeCalledPop:FAIL:Expected "pop" was "coke"

--------------------------
OVERALL UNITY TEST SUMMARY
--------------------------
45 TOTAL TESTS 2 TOTAL FAILURES 1 IGNORED

How convenient is that?

Find The Latest of This And More at ThrowTheSwitch.org

File: README.md Copy Chapter

Unity Test ![CI][]

Getting Started Copy Chapter

Unity Assertion Summary Copy Chapter

Basic Validity Tests Copy Section

Numerical Assertions: Integers Copy Section

Arrays Copy Section

Numerical Assertions: Bitwise Copy Section

Numerical Assertions: Floats Copy Section

String Assertions Copy Section

Pointer Assertions Copy Section

Memory Assertions Copy Section

\_MESSAGE Copy Section

File: docs/CODE_OF_CONDUCT.md Copy Chapter

ThrowTheSwitch.org Code of Conduct

Our Pledge Copy Chapter

Our Standards Copy Chapter

Enforcement Responsibilities Copy Chapter

Scope Copy Chapter

Enforcement Copy Chapter

Enforcement Guidelines Copy Chapter

1. Correction Copy Section

2. Warning Copy Section

3. Temporary Ban Copy Section

4. Permanent Ban Copy Section

Attribution Copy Chapter

File: docs/CONTRIBUTING.md Copy Chapter

Contributing to a ThrowTheSwitch.org Project

Table Of Contents Copy Section

:book: Code of Conduct Copy Chapter

:bulb: Asking Questions Copy Chapter

What should I know before I get started? Copy Section

:inbox_tray: Opening an Issue Copy Chapter

:beetle: Bug Reports and Other Issues Copy Section

:heart: Who Loves Emoji? Copy Chapter

:white_check_mark: Code Review Copy Chapter

:violin: Coding Style Copy Chapter

C Styleguide Copy Section

Ruby Styleguide Copy Section

:medal_sports: Certificate of Origin Copy Chapter

[No Brown M&M's](https://en.wikipedia.org/wiki/Van_Halen#Contract_riders) Copy Chapter

:pray: Credits Copy Chapter

File: docs/MesonGeneratorRunner.md Copy Chapter

Meson Generator - Test Runner

File: docs/ThrowTheSwitchCodingStandard.md Copy Chapter

ThrowTheSwitch.org Coding Standard

Why Have A Coding Standard? Copy Chapter

Our Philosophy Copy Chapter

Naming Things Copy Chapter

Readable Copy Section

Descriptive Copy Section

Consistent Copy Section

Memorable Copy Section

C and C++ Details Copy Chapter

Whitespace in C/C++ Copy Section

Case in C/C++ Copy Section

Braces in C/C++ Copy Section

Comments in C/C++ Copy Section

Ruby Details Copy Chapter

Whitespace in Ruby Copy Section

Case in Ruby Copy Section

Documentation Copy Chapter

File: docs/UnityAssertionsReference.md Copy Chapter

Unity Assertions Reference

Table of Contents Copy Chapter

Background and Overview Copy Chapter

Super Condensed Version Copy Section

Unity Is Several Things But Mainly It’s Assertions Copy Section

What’s an Assertion? Copy Section

Unity’s Assertions: Helpful Messages _and_ Free Source Code Documentation Copy Section

Assertion Conventions and Configurations Copy Chapter

Naming and Parameter Conventions Copy Section

TEST_ASSERT_X_MESSAGE Variants

TEST_ASSERT_X_ARRAY Variants

TEST_ASSERT_EACH_EQUAL_X Variants Copy Section

Configuration Copy Section

Floating Point Support Is Optional

Maximum Data Type Width Is Configurable

The Assertions in All Their Blessed Glory Copy Chapter

Basic Fail, Pass and Ignore Copy Section

File: README.md

Getting Started

Unity Assertion Summary

Basic Validity Tests

Numerical Assertions: Integers

Arrays

Numerical Assertions: Bitwise

Numerical Assertions: Floats

String Assertions

Pointer Assertions

Memory Assertions

\_MESSAGE

File: docs/CODE_OF_CONDUCT.md

Our Pledge

Our Standards

Enforcement Responsibilities

Scope

Enforcement

Enforcement Guidelines

1. Correction

2. Warning

3. Temporary Ban

4. Permanent Ban

Attribution

File: docs/CONTRIBUTING.md

Table Of Contents

:book: Code of Conduct

:bulb: Asking Questions

What should I know before I get started?

:inbox_tray: Opening an Issue

:beetle: Bug Reports and Other Issues

:heart: Who Loves Emoji?

:white_check_mark: Code Review

:violin: Coding Style

C Styleguide

Ruby Styleguide

:medal_sports: Certificate of Origin

[No Brown M&M's](https://en.wikipedia.org/wiki/Van_Halen#Contract_riders)

:pray: Credits

File: docs/MesonGeneratorRunner.md

File: docs/ThrowTheSwitchCodingStandard.md

Why Have A Coding Standard?

Our Philosophy

Naming Things

Readable

Descriptive

Consistent

Memorable

C and C++ Details

Whitespace in C/C++

Case in C/C++

Braces in C/C++

Comments in C/C++

Ruby Details

Whitespace in Ruby

Case in Ruby

Documentation

File: docs/UnityAssertionsReference.md

Table of Contents

Background and Overview

Super Condensed Version

Unity Is Several Things But Mainly It’s Assertions

What’s an Assertion?

Unity’s Assertions: Helpful Messages _and_ Free Source Code Documentation

Assertion Conventions and Configurations

Naming and Parameter Conventions

TEST_ASSERT_EACH_EQUAL_X Variants

Configuration

The Assertions in All Their Blessed Glory

Basic Fail, Pass and Ignore

Boolean

Signed and Unsigned Integers (of all sizes)

Unsigned Integers (of all sizes) in Hexadecimal

Characters

Masked and Bit-level Assertions

Integer Less Than / Greater Than

Integer Ranges (of all sizes)

Structs and Strings