cJSON Documentation

Technical Documentation: DaveGamble/cJSON

ℹ️ Provenance: Multi-Tier Ingestion · CodeWiki Reference

Overview (`README.md`) Copy Section

cJSON

Ultralightweight JSON parser in ANSI C.

Table of contents Copy Chapter

• License
• Usage
  • Welcome to cJSON
  • Building
    • Copying the source
    • CMake
    • Makefile
    • Meson
    • Vcpkg
  • Including cJSON
  • Data Structure
  • Working with the data structure
    • Basic types
    • Arrays
    • Objects
  • Parsing JSON
  • Printing JSON
  • Example
    • Printing
    • Parsing
  • Caveats
    • Zero Character
    • Character Encoding
    • C Standard
    • Floating Point Numbers
    • Deep Nesting Of Arrays And Objects
    • Thread Safety
    • Case Sensitivity
    • Duplicate Object Members
  • Enjoy cJSON!

License Copy Chapter

MIT License

Copyright (c) 2009-2017 Dave Gamble and cJSON contributors

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

Usage Copy Chapter

Welcome to cJSON. Copy Section

cJSON aims to be the dumbest possible parser that you can get your job done with.
It's a single file of C, and a single header file.

JSON is described best here: http://www.json.org/
It's like XML, but fat-free. You use it to move data around, store things, or just
generally represent your program's state.

As a library, cJSON exists to take away as much legwork as it can, but not get in your way.
As a point of pragmatism (i.e. ignoring the truth), I'm going to say that you can use it
in one of two modes: Auto and Manual. Let's have a quick run-through.

I lifted some JSON from this page: http://www.json.org/fatfree.html
That page inspired me to write cJSON, which is a parser that tries to share the same
philosophy as JSON itself. Simple, dumb, out of the way.

Building Copy Section

There are several ways to incorporate cJSON into your project.

copying the source

Because the entire library is only one C file and one header file, you can just copy cJSON.h and cJSON.c to your projects source and start using it.

cJSON is written in ANSI C (C89) in order to support as many platforms and compilers as possible.

CMake

With CMake, cJSON supports a full blown build system. This way you get the most features. CMake with an equal or higher version than 3.5 is supported. With CMake it is recommended to do an out of tree build, meaning the compiled files are put in a directory separate from the source files. So in order to build cJSON with CMake on a Unix platform, make a build directory and run CMake inside it.

mkdir build
cd build
cmake ..

This will create a Makefile and a bunch of other files. You can then compile it:

make

And install it with make install if you want. By default it installs the headers /usr/local/include/cjson and the libraries to /usr/local/lib. It also installs files for pkg-config to make it easier to detect and use an existing installation of CMake. And it installs CMake config files, that can be used by other CMake based projects to discover the library.

You can change the build process with a list of different options that you can pass to CMake. Turn them on with On and off with Off:

• -DENABLE_CJSON_TEST=On: Enable building the tests. (on by default)
• -DENABLE_CJSON_UTILS=On: Enable building cJSON_Utils. (off by default)
• -DENABLE_TARGET_EXPORT=On: Enable the export of CMake targets. Turn off if it makes problems. (on by default)
• -DENABLE_CUSTOM_COMPILER_FLAGS=On: Enable custom compiler flags (currently for Clang, GCC and MSVC). Turn off if it makes problems. (on by default)
• -DENABLE_VALGRIND=On: Run tests with valgrind. (off by default)
• -DENABLE_SANITIZERS=On: Compile cJSON with AddressSanitizer and UndefinedBehaviorSanitizer enabled (if possible). (off by default)
• -DENABLE_SAFE_STACK: Enable the SafeStack instrumentation pass. Currently only works with the Clang compiler. (off by default)
• -DBUILD_SHARED_LIBS=On: Build the shared libraries. (on by default)
• -DBUILD_SHARED_AND_STATIC_LIBS=On: Build both shared and static libraries. (off by default)
• -DCMAKE_INSTALL_PREFIX=/usr: Set a prefix for the installation.
• -DENABLE_LOCALES=On: Enable the usage of localeconv method. ( on by default )
• -DCJSON_OVERRIDE_BUILD_SHARED_LIBS=On: Enable overriding the value of BUILD_SHARED_LIBS with -DCJSON_BUILD_SHARED_LIBS.
• -DENABLE_CJSON_VERSION_SO: Enable cJSON so version. ( on by default )

If you are packaging cJSON for a distribution of Linux, you would probably take these steps for example:

mkdir build
cd build
cmake .. -DENABLE_CJSON_UTILS=On -DENABLE_CJSON_TEST=Off -DCMAKE_INSTALL_PREFIX=/usr
make
make DESTDIR=$pkgdir install

On Windows CMake is usually used to create a Visual Studio solution file by running it inside the Developer Command Prompt for Visual Studio, for exact steps follow the official documentation from CMake and Microsoft and use the online search engine of your choice. The descriptions of the the options above still generally apply, although not all of them work on Windows.

Makefile

NOTE: This Method is deprecated. Use CMake if at all possible. Makefile support is limited to fixing bugs.

If you don't have CMake available, but still have GNU make. You can use the makefile to build cJSON:

Run this command in the directory with the source code and it will automatically compile static and shared libraries and a little test program (not the full test suite).

make all

If you want, you can install the compiled library to your system using make install. By default it will install the headers in /usr/local/include/cjson and the libraries in /usr/local/lib. But you can change this behavior by setting the PREFIX and DESTDIR variables: make PREFIX=/usr DESTDIR=temp install. And uninstall them with: make PREFIX=/usr DESTDIR=temp uninstall.

Meson

To make cjson work in a project using meson, the libcjson dependency has to be included:

project('c-json-example', 'c')

cjson = dependency('libcjson')

example = executable(
    'example',
    'example.c',
    dependencies: [cjson],
)

Vcpkg

You can download and install cJSON using the vcpkg dependency manager:

git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
./bootstrap-vcpkg.sh
./vcpkg integrate install
vcpkg install cjson

The cJSON port in vcpkg is kept up to date by Microsoft team members and community contributors. If the version is out of date, please create an issue or pull request on the vcpkg repository.

Including cJSON Copy Section

If you installed it via CMake or the Makefile, you can include cJSON like this:

#include <cjson/cJSON.h>

Data Structure Copy Section

cJSON represents JSON data using the cJSON struct data type:

/* The cJSON structure: */
typedef struct cJSON
{
    struct cJSON *next;
    struct cJSON *prev;
    struct cJSON *child;
    int type;
    char *valuestring;
    /* writing to valueint is DEPRECATED, use cJSON_SetNumberValue instead */
    int valueint;
    double valuedouble;
    char *string;
} cJSON;

An item of this type represents a JSON value. The type is stored in type as a bit-flag (this means that you cannot find out the type by just comparing the value of type).

To check the type of an item, use the corresponding cJSON_Is... function. It does a NULL check followed by a type check and returns a boolean value if the item is of this type.

The type can be one of the following:

• cJSON_Invalid (check with cJSON_IsInvalid): Represents an invalid item that doesn't contain any value. You automatically have this type if you set the item to all zero bytes.
• cJSON_False (check with cJSON_IsFalse): Represents a false boolean value. You can also check for boolean values in general with cJSON_IsBool.
• cJSON_True (check with cJSON_IsTrue): Represents a true boolean value. You can also check for boolean values in general with cJSON_IsBool.
• cJSON_NULL (check with cJSON_IsNull): Represents a null value.
• cJSON_Number (check with cJSON_IsNumber): Represents a number value. The value is stored as a double in valuedouble and also in valueint. If the number is outside of the range of an integer, INT_MAX or INT_MIN are used for valueint.
• cJSON_String (check with cJSON_IsString): Represents a string value. It is stored in the form of a zero terminated string in valuestring.
• cJSON_Array (check with cJSON_IsArray): Represent an array value. This is implemented by pointing child to a linked list of cJSON items that represent the values in the array. The elements are linked together using next and prev, where the first element has prev.next == NULL and the last element next == NULL.
• cJSON_Object (check with cJSON_IsObject): Represents an object value. Objects are stored same way as an array, the only difference is that the items in the object store their keys in string.
• cJSON_Raw (check with cJSON_IsRaw): Represents any kind of JSON that is stored as a zero terminated array of characters in valuestring. This can be used, for example, to avoid printing the same static JSON over and over again to save performance. cJSON will never create this type when parsing. Also note that cJSON doesn't check if it is valid JSON.

Additionally there are the following two flags:

• cJSON_IsReference: Specifies that the item that child points to and/or valuestring is not owned by this item, it is only a reference. So cJSON_Delete and other functions will only deallocate this item, not its child/valuestring.
• cJSON_StringIsConst: This means that string points to a constant string. This means that cJSON_Delete and other functions will not try to deallocate string.

Working with the data structure Copy Section

For every value type there is a cJSON_Create... function that can be used to create an item of that type.
All of these will allocate a cJSON struct that can later be deleted with cJSON_Delete.
Note that you have to delete them at some point, otherwise you will get a memory leak.
Important: If you have added an item to an array or an object already, you mustn't delete it with cJSON_Delete. Adding it to an array or object transfers its ownership so that when that array or object is deleted,
it gets deleted as well. You also could use cJSON_SetValuestring to change a cJSON_String's valuestring, and you needn't to free the previous valuestring manually.

Basic types

• null is created with cJSON_CreateNull
• booleans are created with cJSON_CreateTrue, cJSON_CreateFalse or cJSON_CreateBool
• numbers are created with cJSON_CreateNumber. This will set both valuedouble and valueint. If the number is outside of the range of an integer, INT_MAX or INT_MIN are used for valueint
• strings are created with cJSON_CreateString (copies the string) or with cJSON_CreateStringReference (directly points to the string. This means that valuestring won't be deleted by cJSON_Delete and you are responsible for its lifetime, useful for constants)

Arrays

You can create an empty array with cJSON_CreateArray. cJSON_CreateArrayReference can be used to create an array that doesn't "own" its content, so its content doesn't get deleted by cJSON_Delete.

To add items to an array, use cJSON_AddItemToArray to append items to the end.
Using cJSON_AddItemReferenceToArray an element can be added as a reference to another item, array or string. This means that cJSON_Delete will not delete that items child or valuestring properties, so no double frees are occurring if they are already used elsewhere.
To insert items in the middle, use cJSON_InsertItemInArray. It will insert an item at the given 0 based index and shift all the existing items to the right.

If you want to take an item out of an array at a given index and continue using it, use cJSON_DetachItemFromArray, it will return the detached item, so be sure to assign it to a pointer, otherwise you will have a memory leak.

Deleting items is done with cJSON_DeleteItemFromArray. It works like cJSON_DetachItemFromArray, but deletes the detached item via cJSON_Delete.

You can also replace an item in an array in place. Either with cJSON_ReplaceItemInArray using an index or with cJSON_ReplaceItemViaPointer given a pointer to an element. cJSON_ReplaceItemViaPointer will return 0 if it fails. What this does internally is to detach the old item, delete it and insert the new item in its place.

To get the size of an array, use cJSON_GetArraySize. Use cJSON_GetArrayItem to get an element at a given index.

Because an array is stored as a linked list, iterating it via index is inefficient (O(n²)), so you can iterate over an array using the cJSON_ArrayForEach macro in O(n) time complexity.

Objects

You can create an empty object with cJSON_CreateObject. cJSON_CreateObjectReference can be used to create an object that doesn't "own" its content, so its content doesn't get deleted by cJSON_Delete.

To add items to an object, use cJSON_AddItemToObject. Use cJSON_AddItemToObjectCS to add an item to an object with a name that is a constant or reference (key of the item, string in the cJSON struct), so that it doesn't get freed by cJSON_Delete.
Using cJSON_AddItemReferenceToArray an element can be added as a reference to another object, array or string. This means that cJSON_Delete will not delete that items child or valuestring properties, so no double frees are occurring if they are already used elsewhere.

If you want to take an item out of an object, use cJSON_DetachItemFromObjectCaseSensitive, it will return the detached item, so be sure to assign it to a pointer, otherwise you will have a memory leak.

Deleting items is done with cJSON_DeleteItemFromObjectCaseSensitive. It works like cJSON_DetachItemFromObjectCaseSensitive followed by cJSON_Delete.

You can also replace an item in an object in place. Either with cJSON_ReplaceItemInObjectCaseSensitive using a key or with cJSON_ReplaceItemViaPointer given a pointer to an element. cJSON_ReplaceItemViaPointer will return 0 if it fails. What this does internally is to detach the old item, delete it and insert the new item in its place.

To get the size of an object, you can use cJSON_GetArraySize, this works because internally objects are stored as arrays.

If you want to access an item in an object, use cJSON_GetObjectItemCaseSensitive.

To iterate over an object, you can use the cJSON_ArrayForEach macro the same way as for arrays.

cJSON also provides convenient helper functions for quickly creating a new item and adding it to an object, like cJSON_AddNullToObject. They return a pointer to the new item or NULL if they failed.

Parsing JSON Copy Section

Given some JSON in a zero terminated string, you can parse it with cJSON_Parse.

cJSON *json = cJSON_Parse(string);

Given some JSON in a string (whether zero terminated or not), you can parse it with cJSON_ParseWithLength.

cJSON *json = cJSON_ParseWithLength(string, buffer_length);

It will parse the JSON and allocate a tree of cJSON items that represents it. Once it returns, you are fully responsible for deallocating it after use with cJSON_Delete.

The allocator used by cJSON_Parse is malloc and free by default but can be changed (globally) with cJSON_InitHooks.

If an error occurs a pointer to the position of the error in the input string can be accessed using cJSON_GetErrorPtr. Note though that this can produce race conditions in multithreading scenarios, in that case it is better to use cJSON_ParseWithOpts with return_parse_end.
By default, characters in the input string that follow the parsed JSON will not be considered as an error.

If you want more options, use cJSON_ParseWithOpts(const char *value, const char **return_parse_end, cJSON_bool require_null_terminated).
return_parse_end returns a pointer to the end of the JSON in the input string or the position that an error occurs at (thereby replacing cJSON_GetErrorPtr in a thread safe way). require_null_terminated, if set to 1 will make it an error if the input string contains data after the JSON.

If you want more options giving buffer length, use cJSON_ParseWithLengthOpts(const char *value, size_t buffer_length, const char **return_parse_end, cJSON_bool require_null_terminated).

Printing JSON Copy Section

Given a tree of cJSON items, you can print them as a string using cJSON_Print.

char *string = cJSON_Print(json);

It will allocate a string and print a JSON representation of the tree into it. Once it returns, you are fully responsible for deallocating it after use with your allocator. (usually free, depends on what has been set with cJSON_InitHooks).

cJSON_Print will print with whitespace for formatting. If you want to print without formatting, use cJSON_PrintUnformatted.

If you have a rough idea of how big your resulting string will be, you can use cJSON_PrintBuffered(const cJSON *item, int prebuffer, cJSON_bool fmt). fmt is a boolean to turn formatting with whitespace on and off. prebuffer specifies the first buffer size to use for printing. cJSON_Print currently uses 256 bytes for its first buffer size. Once printing runs out of space, a new buffer is allocated and the old gets copied over before printing is continued.

These dynamic buffer allocations can be completely avoided by using cJSON_PrintPreallocated(cJSON *item, char *buffer, const int length, const cJSON_bool format). It takes a buffer to a pointer to print to and its length. If the length is reached, printing will fail and it returns 0. In case of success, 1 is returned. Note that you should provide 5 bytes more than is actually needed, because cJSON is not 100% accurate in estimating if the provided memory is enough.

Example Copy Section

In this example we want to build and parse the following JSON:

{
    "name": "Awesome 4K",
    "resolutions": [
        {
            "width": 1280,
            "height": 720
        },
        {
            "width": 1920,
            "height": 1080
        },
        {
            "width": 3840,
            "height": 2160
        }
    ]
}

Printing

Let's build the above JSON and print it to a string:

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

Alternatively we can use the cJSON_Add...ToObject helper functions to make our lives a little easier:

//NOTE: Returns a heap allocated string, you are required to free it after use.
char *create_monitor_with_helpers(void)
{
    const unsigned int resolution_numbers[3][2] = {
        {1280, 720},
        {1920, 1080},
        {3840, 2160}
    };
    char *string = NULL;
    cJSON *resolutions = NULL;
    size_t index = 0;

    cJSON *monitor = cJSON_CreateObject();

    if (cJSON_AddStringToObject(monitor, "name", "Awesome 4K") == NULL)
    {
        goto end;
    }

    resolutions = cJSON_AddArrayToObject(monitor, "resolutions");
    if (resolutions == NULL)
    {
        goto end;
    }

    for (index = 0; index < (sizeof(resolution_numbers) / (2 * sizeof(int))); ++index)
    {
        cJSON *resolution = cJSON_CreateObject();

        if (cJSON_AddNumberToObject(resolution, "width", resolution_numbers[index][0]) == NULL)
        {
            goto end;
        }

        if (cJSON_AddNumberToObject(resolution, "height", resolution_numbers[index][1]) == NULL)
        {
            goto end;
        }

        cJSON_AddItemToArray(resolutions, resolution);
    }

    string = cJSON_Print(monitor);
    if (string == NULL)
    {
        fprintf(stderr, "Failed to print monitor.\n");
    }

end:
    cJSON_Delete(monitor);
    return string;
}

Parsing

In this example we will parse a JSON in the above format and check if the monitor supports a Full HD resolution while printing some diagnostic output:

/* return 1 if the monitor supports full hd, 0 otherwise */
int supports_full_hd(const char * const monitor)
{
    const cJSON *resolution = NULL;
    const cJSON *resolutions = NULL;
    const cJSON *name = NULL;
    int status = 0;
    cJSON *monitor_json = cJSON_Parse(monitor);
    if (monitor_json == NULL)
    {
        const char *error_ptr = cJSON_GetErrorPtr();
        if (error_ptr != NULL)
        {
            fprintf(stderr, "Error before: %s\n", error_ptr);
        }
        status = 0;
        goto end;
    }

    name = cJSON_GetObjectItemCaseSensitive(monitor_json, "name");
    if (cJSON_IsString(name) && (name->valuestring != NULL))
    {
        printf("Checking monitor \"%s\"\n", name->valuestring);
    }

    resolutions = cJSON_GetObjectItemCaseSensitive(monitor_json, "resolutions");
    cJSON_ArrayForEach(resolution, resolutions)
    {
        cJSON *width = cJSON_GetObjectItemCaseSensitive(resolution, "width");
        cJSON *height = cJSON_GetObjectItemCaseSensitive(resolution, "height");

        if (!cJSON_IsNumber(width) || !cJSON_IsNumber(height))
        {
            status = 0;
            goto end;
        }

        if ((width->valuedouble == 1920) && (height->valuedouble == 1080))
        {
            status = 1;
            goto end;
        }
    }

end:
    cJSON_Delete(monitor_json);
    return status;
}

Note that there are no NULL checks except for the result of cJSON_Parse because cJSON_GetObjectItemCaseSensitive checks for NULL inputs already, so a NULL value is just propagated and cJSON_IsNumber and cJSON_IsString return 0 if the input is NULL.

Caveats Copy Section

Zero Character

cJSON doesn't support strings that contain the zero character '\0' or \u0000. This is impossible with the current API because strings are zero terminated.

Character Encoding

cJSON only supports UTF-8 encoded input. In most cases it doesn't reject invalid UTF-8 as input though, it just propagates it through as is. As long as the input doesn't contain invalid UTF-8, the output will always be valid UTF-8.

C Standard

cJSON is written in ANSI C (or C89, C90). If your compiler or C library doesn't follow this standard, correct behavior is not guaranteed.

NOTE: ANSI C is not C++ therefore it shouldn't be compiled with a C++ compiler. You can compile it with a C compiler and link it with your C++ code however. Although compiling with a C++ compiler might work, correct behavior is not guaranteed.

Floating Point Numbers

cJSON does not officially support any double implementations other than IEEE754 double precision floating point numbers. It might still work with other implementations but bugs with these will be considered invalid.

The maximum length of a floating point literal that cJSON supports is currently 63 characters.

Deep Nesting Of Arrays And Objects

cJSON doesn't support arrays and objects that are nested too deeply because this would result in a stack overflow. To prevent this cJSON limits the depth to CJSON_NESTING_LIMIT which is 1000 by default but can be changed at compile time.

Thread Safety

In general cJSON is not thread safe.

However it is thread safe under the following conditions:

• cJSON_GetErrorPtr is never used (the return_parse_end parameter of cJSON_ParseWithOpts can be used instead)
• cJSON_InitHooks is only ever called before using cJSON in any threads.
• setlocale is never called before all calls to cJSON functions have returned.

Case Sensitivity

When cJSON was originally created, it didn't follow the JSON standard and didn't make a distinction between uppercase and lowercase letters. If you want the correct, standard compliant, behavior, you need to use the CaseSensitive functions where available.

Duplicate Object Members

cJSON supports parsing and printing JSON that contains objects that have multiple members with the same name. cJSON_GetObjectItemCaseSensitive however will always only return the first one.

Enjoy cJSON!

• Dave Gamble (original author)
• Max Bruckner and Alan Wang (current maintainer)
• and the other cJSON contributors

Overview (`tests/json-patch-tests/README.md`) Copy Section

JSON Patch Tests

These are test cases for implementations of IETF JSON Patch (RFC6902).

Some implementations can be found at jsonpatch.com.

Test Format Copy Chapter

Each test file is a JSON document that contains an array of test records. A
test record is an object with the following members:

• doc: The JSON document to test against
• patch: The patch(es) to apply
• expected: The expected resulting document, OR
• error: A string describing an expected error
• comment: A string describing the test
• disabled: True if the test should be skipped

All fields except 'doc' and 'patch' are optional. Test records consisting only
of a comment are also OK.

Files Copy Chapter

• tests.json: the main test file
• spec_tests.json: tests from the RFC6902 spec

Writing Tests Copy Chapter

All tests should have a descriptive comment. Tests should be as
simple as possible - just what's required to test a specific piece of
behavior. If you want to test interacting behaviors, create tests for
each behavior as well as the interaction.

If an 'error' member is specified, the error text should describe the
error the implementation should raise - not what's being tested.
Implementation error strings will vary, but the suggested error should
be easily matched to the implementation error string. Try to avoid
creating error tests that might pass because an incorrect error was
reported.

Please feel free to contribute!

Credits Copy Chapter

The seed test set was adapted from Byron Ruth's
jsonpatch-js and
extended by Mike McCabe.

License Copy Chapter

Copyright 2014 The Authors

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

Overview (`tests/unity/README.md`) Copy Section

Unity Test API

Copyright (c) 2007 - 2017 Unity Project by Mike Karlesky, Mark VanderVoord, and Greg Williams

Running Tests Copy Chapter

RUN_TEST(func, linenum)

Each Test is run within the macro RUN_TEST. This macro performs necessary setup before the test is called and handles cleanup and result tabulation afterwards.

Ignoring Tests Copy Chapter

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.

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 Copy Chapter

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.

Unity Assertion Summary

Basic Validity Tests Copy Chapter

TEST_ASSERT_TRUE(condition)

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

TEST_ASSERT_FALSE(condition)

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

TEST_ASSERT(condition)

Another way of calling TEST_ASSERT_TRUE

TEST_ASSERT_UNLESS(condition)

Another way of calling TEST_ASSERT_FALSE

TEST_FAIL()
TEST_FAIL_MESSAGE(message)

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

Numerical Assertions: Integers Copy Chapter

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,
like when comparing arrays, you can use a specific version:

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.

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 effect how many nibbles are shown (for example, HEX16
will show 4 nibbles).

TEST_ASSERT_EQUAL(expected, actual)

Another way of calling TEST_ASSERT_EQUAL_INT

TEST_ASSERT_INT_WITHIN(delta, expected, actual)

Asserts that the actual value is within plus or minus delta of the expected value. This also comes in
size specific variants.

TEST_ASSERT_GREATER_THAN(threshold, actual)

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

TEST_ASSERT_LESS_THAN(threshold, actual)

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

Arrays Copy Chapter

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

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:

TEST_ASSERT_EACH_EQUAL_INT32(expected, actual, elements)

Numerical Assertions: Bitwise Copy Chapter

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.

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.

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.

TEST_ASSERT_BIT_HIGH(bit, actual)

Test a single bit and verify that it is high. The bit is specified 0-31 for a 32-bit integer.

TEST_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 Copy Chapter

TEST_ASSERT_FLOAT_WITHIN(delta, expected, actual)

Asserts that the actual value is within plus or minus delta of the expected value.

TEST_ASSERT_EQUAL_FLOAT(expected, actual)
TEST_ASSERT_EQUAL_DOUBLE(expected, actual)

Asserts that two floating point values are "equal" within a small % delta of the expected value.

String Assertions Copy Chapter

TEST_ASSERT_EQUAL_STRING(expected, actual)

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

TEST_ASSERT_EQUAL_STRING_LEN(expected, actual, len)

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

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.

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 Copy Chapter

Most pointer operations can be performed by simply using the integer comparisons above. However, a couple of special cases are added for clarity.

TEST_ASSERT_NULL(pointer)

Fails if the pointer is not equal to NULL

TEST_ASSERT_NOT_NULL(pointer)

Fails if the pointer is equal to NULL

Memory Assertions Copy Chapter

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 Copy Chapter

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.

Tests Unity Docs ThrowTheSwitchCodingStandard (`tests/unity/docs/ThrowTheSwitchCodingStandard.md`) Copy Section

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? Copy Chapter

Being consistent makes code easier to understand. We've made an attempt 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 Copy Chapter

Before we get into details on syntax, let's take a moment to talk about our
vision for these tools. We're C developers and embedded software developers.
These tools are great to test any C code, but catering to embedded software has
made us more tolerant of compiler quirks. There are a LOT of quirky compilers
out there. By quirky I mean "doesn't follow standards because they feel like
they have a license to do as they wish."

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 Copy Chapter

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 quite a bit of effort into
finding What Something WANTS to be Called™.

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

1. Readable
2. Descriptive
3. Consistent
4. 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 endeavor. You might notice
from poking around our code that this often results in names that are a little
longer than the average. Guilty. We're okay with a tiny 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
therefore 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 Copy Chapter

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

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

• 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

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

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 Copy Chapter

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

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

• 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 Copy Chapter

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

Tests Unity Docs UnityAssertionsReference (`tests/unity/docs/UnityAssertionsReference.md`) Copy Section

Unity Assertions Reference

Background and Overview Copy Chapter

Super Condensed Version Copy Section

• 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 Copy Section

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? Copy Section

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 (to appreciate the big
picture on this read up on the difference between
[link:Dynamic Verification and Static Analysis]). A failing assertion stops
execution and reports an error through some appropriate I/O channel (e.g.
stdout, GUI, 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 Copy Section

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 Copy Chapter

Naming and Parameter Conventions Copy Section

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

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 Copy Section

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 Copy Section

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 Copy Chapter

Basic Fail and Ignore Copy Section

`TEST_FAIL()`

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_IGNORE()`

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

Boolean Copy Section

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

Signed and Unsigned Integers (of all sizes) Copy Section

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 (expected, actual)`

`TEST_ASSERT_NOT_EQUAL (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 Copy Section

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

Masked and Bit-level Assertions Copy Section

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 Copy Section

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.

`TEST_ASSERT_GREATER_THAN (threshold, actual)`

`TEST_ASSERT_GREATER_THAN_INT (threshold, actual)`

`TEST_ASSERT_GREATER_THAN_INT8 (threshold, actual)`

`TEST_ASSERT_GREATER_THAN_INT16 (threshold, actual)`

`TEST_ASSERT_GREATER_THAN_INT32 (threshold, actual)`

`TEST_ASSERT_GREATER_THAN_UINT (threshold, actual)`

`TEST_ASSERT_GREATER_THAN_UINT8 (threshold, actual)`

`TEST_ASSERT_GREATER_THAN_UINT16 (threshold, actual)`

`TEST_ASSERT_GREATER_THAN_UINT32 (threshold, actual)`

`TEST_ASSERT_GREATER_THAN_HEX8 (threshold, actual)`

`TEST_ASSERT_GREATER_THAN_HEX16 (threshold, actual)`

`TEST_ASSERT_GREATER_THAN_HEX32 (threshold, actual)`

`TEST_ASSERT_LESS_THAN (threshold, actual)`

`TEST_ASSERT_LESS_THAN_INT (threshold, actual)`

`TEST_ASSERT_LESS_THAN_INT8 (threshold, actual)`

`TEST_ASSERT_LESS_THAN_INT16 (threshold, actual)`

`TEST_ASSERT_LESS_THAN_INT32 (threshold, actual)`

`TEST_ASSERT_LESS_THAN_UINT (threshold, actual)`

`TEST_ASSERT_LESS_THAN_UINT8 (threshold, actual)`

`TEST_ASSERT_LESS_THAN_UINT16 (threshold, actual)`

`TEST_ASSERT_LESS_THAN_UINT32 (threshold, actual)`

`TEST_ASSERT_LESS_THAN_HEX8 (threshold, actual)`

`TEST_ASSERT_LESS_THAN_HEX16 (threshold, actual)`

`TEST_ASSERT_LESS_THAN_HEX32 (threshold, actual)`

Integer Ranges (of all sizes) Copy Section

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

Structs and Strings Copy Section

`TEST_ASSERT_EQUAL_PTR (expected, actual)`

Asserts that the pointers point to the same memory location.

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

Arrays Copy Section

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

Each Equal (Arrays to Single Value) Copy Section

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_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) Copy Section

`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_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_EQUAL_FLOAT_ARRAY (expected, actual, num_elements)`

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

`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) Copy Section

`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_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_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_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)`

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_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)`

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.

Advanced Asserting: Details On Tricky Assertions Copy Chapter

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? Copy Section

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
0 x 20or 0 x 263.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? Copy Section

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:

1. When Unity displays errors for you, it's going to pad the upper unused bits
   with zeros.
2. 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

Tests Unity Docs UnityConfigurationGuide (`tests/unity/docs/UnityConfigurationGuide.md`) Copy Section

Unity Configuration Guide

C Standards, Compilers and Microcontrollers Copy Chapter

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 in order to
provide a more consistent and simple experience elsewhere.

Using These Options Copy Section

It doesn't matter if you're using a target-specific compiler and a simulator or
a native compiler. In either case, you've got a couple choices for configuring
these options:

1. Because these options are specified via C defines, you can pass most of these
   options to your compiler through command line compiler flags. Even if you're
   using an embedded target that forces you to use their overbearing IDE for all
   configuration, there will be a place somewhere in your project to configure
   defines for your compiler.
2. You can create a custom unity_config.h configuration file (present in your
   toolchain's search paths). In this file, you will list definitions and macros
   specific to your target. All you must do is define UNITY_INCLUDE_CONFIG_H and
   Unity will rely on unity_config.h for any further definitions it may need.

The Options Copy Chapter

Integer Types Copy Section

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 make use of 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.

Example:
#define UNITY_POINTER_WIDTH 64

`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 Copy Section

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

Toolset Customization Copy Section

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

#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. If you
specify a custom flush function instead with UNITY_OUTPUT_FLUSH directly, it
will declare an instance of your function by default. If you want to disable
this behavior, add UNITY_OMIT_OUTPUT_FLUSH_HEADER_DECLARATION.

`UNITY_WEAK_ATTRIBUTE`

`UNITY_WEAK_PRAGMA`

`UNITY_NO_WEAK`

For some targets, Unity can make the otherwise required setUp() and tearDown()
functions optional. This is a nice convenience for test writers since setUp and
tearDown don’t often actually do anything. If you’re using gcc or clang, this
option is automatically defined for you. Other compilers can also support this
behavior, if they support a C feature called weak functions. A weak function is
a function that is compiled into your executable unless a non-weak version of
the same function is defined elsewhere. If a non-weak version is found, the weak
version is ignored as if it never existed. If your compiler supports this feature,
you can let Unity know by defining UNITY_WEAK_ATTRIBUTE or UNITY_WEAK_PRAGMA as
the function attributes that would need to be applied to identify a function as
weak. If your compiler lacks support for weak functions, you will always need to
define setUp and tearDown functions (though they can be and often will be just
empty). You can also force Unity to NOT use weak functions by defining
UNITY_NO_WEAK. The most common options for this feature are:

Example:
#define UNITY_WEAK_ATTRIBUTE weak
#define UNITY_WEAK_ATTRIBUTE attribute((weak))
#define UNITY_WEAK_PRAGMA
#define UNITY_NO_WEAK

`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_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_OUTPUT_COLOR`

If you want to add color using ANSI escape codes you can use this define.
t
Example:
#define UNITY_OUTPUT_COLOR

Getting Into The Guts Copy Chapter

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 Copy Chapter

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

Tests Unity Docs UnityGettingStartedGuide (`tests/unity/docs/UnityGettingStartedGuide.md`) Copy Section

Unity - Getting Started

Welcome Copy Chapter

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 Copy Section

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 Copy Section

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 addons 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 Copy Chapter

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

Next, a test file will include a setUp() and tearDown() function. The setUp
function can contain anything you would like to run before each test. The
tearDown function can contain anything you would like to run after each test.
Both functions accept no arguments and return nothing. You may leave either or
both of these blank if you have no need for them. If you're using a compiler
that is configured to make these functions optional, you may leave them off
completely. Not sure? Give it a try. If you compiler complains that it can't
find setUp or tearDown when it links, you'll know you need to at least include
an empty function for these.

The majority of the file will be a series of test functions. Test functions
follow the convention of starting with the word "test" or "spec". You don't HAVE
to name them this way, but it makes it clear what functions are tests for other
developers. Test functions take no arguments and return nothing. All test
accounting is handled internally in Unity.

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

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

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

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

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

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

void test_function_should_doBlahAndBlah(void) {
    //test stuff
}

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

int main(void) {
    UNITY_BEGIN();
    RUN_TEST(test_function_should_doBlahAndBlah);
    RUN_TEST(test_function_should_doAlsoDoBlah);
    return UNITY_END();
}

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

How to Build and Run A Test File Copy Chapter

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

Tests Unity Docs UnityHelperScriptsGuide (`tests/unity/docs/UnityHelperScriptsGuide.md`) Copy Section

Unity Helper Scripts

With a Little Help From Our Friends Copy Chapter

Sometimes what it takes to be a really efficient C programmer is a little non-C.
The Unity project includes a couple Ruby scripts for making your life just a tad
easier. They are completely optional. If you choose to use them, you'll need a
copy of Ruby, of course. Just install whatever the latest version is, and it is
likely to work. You can find Ruby at ruby-lang.org.

`generate_test_runner.rb` Copy Section

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:

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.

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.

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.

:unity:
  :includes:
    - stdio.h
    - microdefs.h
  :cexception: 1
  :suit_setup: "blah = malloc(1024);"
  :suite_teardown: "free(blah);"

If you would like to force your generated test runner to include one or more
header files, you can just include those at the command line too. Just make sure
these are after the YAML file, if you are using one:

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:

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

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

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

Options accepted by generate_test_runner.rb:

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

`:includes`

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

`:suite_setup`

Define this option with C code to be executed before any test cases are run.

Alternatively, if your C compiler supports weak symbols, you can leave this
option unset and instead provide a void suiteSetUp(void) function in your test
suite. The linker will look for this symbol and fall back to a Unity-provided
stub if it is not found.

`:suite_teardown`

Define this option with C code to be executed after all test cases have
finished. An integer variable num_failures is available for diagnostics.
The code should end with a return statement; the value returned will become
the exit code of main. You can normally just return num_failures.

Alternatively, if your C compiler supports weak symbols, you can leave this
option unset and instead provide a int suiteTearDown(int num_failures)
function in your test suite. The linker will look for this symbol and fall
back to a Unity-provided stub if it is not found.

`:enforce_strict_ordering`

This option should be defined if you have the strict order feature enabled in
CMock (see CMock documentation). This generates extra variables required for
everything to run smoothly. If you provide the same YAML to the generator as
used in CMock's configuration, you've already configured the generator properly.

`:plugins`

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

:plugins => [ :cexception ]

Or as a yaml file:

:plugins:
  -:cexception

If you are using CMock, it is very likely that you are already passing an array
of plugins to CMock. You can just use the same array here. This script will just
ignore the plugins that don't require additional support.

`unity_test_summary.rb` Copy Section

A Unity test file contains one or more test case functions. Each test case can
pass, fail, or be ignored. Each test file is run individually producing results
for its collection of test cases. A given project will almost certainly be
composed of multiple test files. Therefore, the suite of tests is comprised of
one or more test cases spread across one or more test files. This script
aggregates individual test file results to generate a summary of all executed
test cases. The output includes how many tests were run, how many were ignored,
and how many failed. In addition, the output includes a listing of which
specific tests were ignored and failed. A good example of the breadth and
details of these results can be found in the examples directory. Intentionally
ignored and failing tests in this project generate corresponding entries in the
summary report.

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

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

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.

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

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

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

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

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

Tests Unity Docs License (`tests/unity/docs/license.txt`) Copy Section

The MIT License (MIT)

Copyright (c) 2007-14 Mike Karlesky, Mark VanderVoord, Greg Williams

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

--- METRICS ---

• Files Extracted: 9
• Estimated Token Budget: ~27510 tokens
• Canonical Reference: https://codewiki.google/github.com/DaveGamble/cJSON