Simple Unit Testing for C

Related tags

Debug Unity
Overview

Unity Test CI

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

Welcome to the Unity Test Project, one of the main projects of ThrowTheSwitch.org. Unity Test is a unit testing framework built for C, with a focus on working with embedded toolchains.

This project is made to test code targetting microcontrollers big and small. The core project is a single C file and a pair of headers, allowing it to the added to your existing build setup without too much headache. You may use any compiler you wish, and may use most existing build systems including make, cmake, etc. If you'd like to leave the hard work to us, you might be interested in Ceedling, a build tool also by ThrowTheSwitch.org.

If you're new to Unity, we encourage you to tour the getting started guide

Getting Started

The docs folder contains a getting started guide and much more tips about using Unity.

Unity Assertion Summary

For the full list, see UnityAssertionsReference.md.

Basic Validity Tests

TEST_ASSERT_TRUE(condition)

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

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

_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

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

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

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

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

TEST_ASSERT_EQUAL_MEMORY(expected, actual, len)

Compare two blocks of memory. This is a good generic assertion for types that can't be coerced into acting like standard types... but since it's a memory compare, you have to be careful that your data types are packed.

_MESSAGE

you can append _MESSAGE to any of the macros to make them take an additional argument. This argument is a string that will be printed at the end of the failure strings. This is useful for specifying more information about the problem.

Comments
  • Print numbers in higher precision in UnityPrintFloat

    Print numbers in higher precision in UnityPrintFloat

    The new implementation of UnityPrintFloat was mostly worse than the existing one. This branch reverts the changes and then adds back the key features of that branch.

    The new attempt had a few drawbacks. It only printed 6 digit of precision, whereas the existing code printed 9+ correctly. You need 9 digits to differentiate single-precision floating point numbers. It had mistakes, rounding errors in the 6th digit on millions of float values. Finally, it covered up the correctness problems by using tests that ignored the last digit.

    The existing implementation didn't attempt to print very small values (< 0.000001). Don't throw the baby out with the bathwater! It also didn't print negative zero as -0.0. Let's keep these two ideas: printing -0.0, and print 6 digits (for now) for very small float values.

    • Revert "Merge pull request #291"
    • Cherry pick code attributed to author of commit 0e7eb54
    • Clean up and match printing style
    opened by jsalling 27
  • Flush function can't be omitted

    Flush function can't be omitted

    Hi,

    We are using Unity with output-char putting a character directly to the console. But we can't omit the new Flush function added in commit c5c392b18a21b048ceb6f728bb7dea84c6e20db5.

    When I define UNITY_OUTPUT_FLUSH or UNITY_OUTPUT_FLUSH() it fails at the https://github.com/ThrowTheSwitch/Unity/blob/master/src/unity_internals.h#L308 declaration.

    For -D'UNITY_OUTPUT_FLUSH()': error: macro "UNITY_OUTPUT_FLUSH" passed 1 arguments, but takes just 0

    for -DUNITY_OUTPUT_FLUSH:

    error: expected identifier or '(' before numeric constant
    ../Unity/src/unity_internals.h:308:13: note: in expansion of macro 'UNITY_OUTPUT_FLUSH'
     extern void UNITY_OUTPUT_FLUSH(void);
                 ^
    

    for -DUNITY_OMIT_OUTPUT_FLUSH_HEADER_DECLARATION -DUNITY_OUTPUT_FLUSH:

    <command-line>:0:20: error: expected identifier or '(' before numeric constant
    ../Unity/src/unity.c:15:5: note: in expansion of macro 'UNITY_OUTPUT_FLUSH'
     int UNITY_OUTPUT_FLUSH(void);
         ^
    

    for -DUNITY_OMIT_OUTPUT_FLUSH_HEADER_DECLARATION -D'UNITY_OUTPUT_FLUSH()':

    ../Unity/src/unity.c:15:28: error: macro "UNITY_OUTPUT_FLUSH" passed 1 arguments, but takes just 0
     int UNITY_OUTPUT_FLUSH(void);
                                ^
    

    I'm out of combinations. I also tried thinks like: -D'UNITY_OUTPUT_FLUSH()'='(void)' I just want to omit this feature which is unneeded for our case.

    Having odd forward declarations all over the shop seems a bit odd. Perhaps a UNITY_HAS_FLUSH and UNITY_FLUSH_FORWARD_DECL config options are more desirable than the current situation.

    Kind regards,

    Rik

    opened by rikvdh 16
  • [regression] Undefined references to setUp and tearDown

    [regression] Undefined references to setUp and tearDown

    Please revert commit 45020b0d3b03; it causes the following build errors on MinGW when setUp() and tearDown() are not overridden (i.e. when relying on the weak symbols):

    ld.exe: unity.o: in function `UnityDefaultTestRun': unity.c:1748: undefined reference to `setUp'
    ld.exe: unity.c:1753: undefined reference to `tearDown'
    collect2.exe: error: ld returned 1 exit status
    

    Note that under MinGW, weak symbols need to be defined in the same module that references them. I made a note of this in https://github.com/ThrowTheSwitch/Unity/blob/2939c420ed9f2697bcb82c1b193bb48c4a8ad7a9/src/unity.h#L33 but it appears to have been overlooked.

    The correct fix for #417 would be to make sure that neither UNITY_WEAK_ATTRIBUTE nor UNITY_WEAK_PRAGMA are defined when using the TI C55x compiler. That's how you're supposed to tell Unity that the compiler doesn't support weak symbols, and in that case, UNITY_INCLUDE_SETUP_STUBS will do nothing.

    opened by jlindgren90 14
  • Adding within API support for float & double arrays

    Adding within API support for float & double arrays

    • Implementing feature requests #630 & #574
    • Fixing copy-paste bug with UnityFloatsWithin usage instead of UnityDoublesWithin
    • Adding lost entries for exclusion (float & double)
    opened by AJIOB 13
  • Some minor changes for parse_output.rb

    Some minor changes for parse_output.rb

    If i understand correctly this is the script for the raw unity output to JUnit style xml and overall test summary. I modified the script in four different ways to get it working:

    • The String split now works correctly didn't work correct on windows ("") platforms and unix based ("/") platforms.

    • Removed the unnecessary whitespaces in the xml output, i needed this for the interpretation of the tools. It was really ugly and sometimes there were 2 whitespaces at front of a message.

    • Added support for the TEST_IGNORE() macro which outputs no message. This wasn't considered in the summary at all.

    • Added the name property to the testsuite tag in the xml output for completeness reasons.

    opened by farrrb 12
  • Only the first test runs from the command prompt

    Only the first test runs from the command prompt

    From a prompt I can run this: xterm -T ./SomeProgram -e /usr/bin/cb_console_runner LD_LIBRARY_PATH=$LD_LIBRARY_PATH:. /home/pi/Documents/Codeblocks_Projects/SomeProgram_WithUnitTests/bin/UnitTest/SomeProgram

    ...and it works just fine. From a terminal window if I run ./SomeProgram it stops after the first test. I did try to take away the xterm -T from the above but it does the same thing. What am I doing wrong?

    opened by Darren996 12
  • Unity, TEST_ASSERT_EQUAL_MEMORY fails

    Unity, TEST_ASSERT_EQUAL_MEMORY fails

    Hello kind folks, I come seeking wisdom!! :-)

    There is a specific issue with Unity that I have come across yesterday and despite my best efforts I am unable to fix it. I have a header file (DriverDS.h) that contains the structure definitions for some custom datastructures I would like to use. The I have DS.c/.h and test_DS.c files which I have created using ceedling module generator. I would like to test a function DSInit.

    DSInit takes two parameters - an enum which indicates the type of datastructure to initialize and a void pointer which has to be initialized based on the enum.

    I have a test in test_DS.c which basically creates a void pointer (pPtrUnderTest), a pointer to the custom datastructure (pExpectedValues). The test first initializes the pExpectedValues pointer to the default zero state, then passes in the pPtrUnderTest to the DSInit function.

    The function itself is supposed to malloc memory for the pointer, depending on the enum, cast the pointer and set the values to null.

    I check if both the pPtrUnderTest and pExpectedValues are equal after the function invocation and would expect them to be equal. However, this test fails. I am not sure where I am making a mistake. I would appreciate any help in fixing this error.

    DriverDS.h

    #ifndef DRIVER_DS
    #define DRIVER_DS
    #include "stdint.h"
    struct POSTResults
    {
    	// Good is 1, Bad is 0
    	bool Battery;
    	bool Authentication;
    	bool Transport;
    };
    
    typedef struct RuntimeSettings
    {
    	char TimeStamp[20];
    	uint16_t POSTInterval; // Interval is specified in seconds
    	struct POSTResults POST;
    } Settings;
    
    #endif // DRIVER_DS
    
    

    DS.h

    #ifndef DS_H
    	#define DS_H
    	#include "BSP.h"
    	#include "DriverDS.h"
    
    	enum Error_codes DSInit(enum DataStructures, void *pStructure);
    
    #endif // DS_H
    
    

    DS.c

    #include "DS.h"
    #include "stdlib.h"
    #include "stdio.h"
    #include "string.h"
    //Pass in a void pointer for the memory block
    // cast the void pointer to a the appropriate structure type and malloc memory for it.
    // Set each member to null
    //
    enum Error_codes DSInit(enum DataStructures dstype, void *pStructure)
    {
    	switch (dstype)
    		{
    		case SETTINGS:
    				pStructure = malloc(sizeof(Settings));
    				memset(((Settings *)pStructure)->TimeStamp, 0, sizeof(((Settings *)pStructure)->TimeStamp));
    				((Settings *)pStructure)->POSTInterval = 0;
    				((Settings *)pStructure)->POST.Authentication = true;
    				((Settings *)pStructure)->POST.Battery = true;
    				((Settings *)pStructure)->POST.Transport = true;
    
    				break;
    			case HWINFO:
    				break;
    			case DATASTRUCTURES_MAX:
    				return ERROR;
    			}
    		return SUCCESS;
    	}
    
    

    test_DS.c

    
    #ifdef TEST
    
    #include "unity.h"
    
    #include "DS.h"
    #include "DriverDS.h"
    #include "string.h"
    #include "stdlib.h"
    void setUp(void)
    {
    }
    
    void tearDown(void)
    {
    }
    
    void test_DS_DSInit_Settings_initializes_values_to_0(void)
    {
    	void *pPtrUnderTest;
    	Settings *pExpectedValues = malloc(sizeof(Settings));
    	memset(pExpectedValues->TimeStamp, 0, sizeof(pExpectedValues->TimeStamp));
    	pExpectedValues->POSTInterval = 0;
    	pExpectedValues->POST.Authentication = true;
    	pExpectedValues->POST.Battery = true;
    	pExpectedValues->POST.Transport = true;
    	DSInit(SETTINGS, pPtrUnderTest);
    	// TEST_ASSERT_EQUAL_PTR(pExpectedValues, (Settings *)pPtrUnderTest);
    	TEST_ASSERT_EQUAL_MEMORY(pExpectedValues, (Settings *)pPtrUnderTest, sizeof(Settings));
    }
    
    #endif // TEST
    
    

    Now the test fails whether I compare PTR or MEMORY.

    I see this error on the console.

     ceedling test:DS
    
    
    Test 'test_DS.c'
    ----------------
    Generating runner for test_DS.c...
    Compiling test_DS_runner.c...
    Compiling test_DS.c...
    Compiling unity.c...
    Compiling DS.c...
    Compiling cmock.c...
    Linking test_DS.out...
    Running test_DS.out...
    
    -------------------
    FAILED TEST SUMMARY
    -------------------
    [test_DS.c]
      Test: test_DS_DSInit_Settings_initializes_values_to_0
      At line (30): "Memory Mismatch. Byte 0 Expected 0x00 Was 0x40"
    
    --------------------
    OVERALL TEST SUMMARY
    --------------------
    TESTED:  1
    PASSED:  0
    FAILED:  1
    IGNORED: 0
    
    ---------------------
    BUILD FAILURE SUMMARY
    ---------------------
    Unit test failures.
    

    The file BSP.h contains the enum Error_codes definition which for now is just ERROR or SUCCESS.

    From what I see here, the pExpectedValues are being set to 0 but the function under test is not setting the memory contents to 0. However, it is the same sequence of operation in the test module and the actual function under test. I have literally copy pasted the code from the test file to the function and renamed it accordingly. I m not sure what is the error I m commiting here.

    I appreciate any insight and help into where I am goofing this up.

    Thanks in advance again folks!! 😄

    PS: To help troubleshoot, I have inserted printf statements inside the function DSInit to print the values after setting them to 0. They are set correctly.

    opened by krish2487 11
  • Add test runner interface.

    Add test runner interface.

    I'm submitting this pull request as a "Request For Comment" since it's a little bit of a design change to the test-runner-generator, so I'd like to hear any concerns or ideas as to how to do this better.

    (Summary from the commit message follows:)

    This standardizes the form of many of the functions in the auto-generated test runners, using the UnityRunner_ prefix. The initial goal was to make UnityRunner_Verify() accessible from within tests -- this is useful for verifying the call chain halfway through a longer, integration-style test.

    A new UnityRunner_RunTest function replaces the generated RUN_TEST macro. It requires test functions to be of the form "void func(void)", so parameterized tests are now handled by creating a tiny wrapper that passes the desired arguments to the actual test.

    Commonizing UnityRunner_RunTest significantly reduces the size of the compiled binary. On amd64, the largest test runner in the test suite (testsample_DefaultsThroughCommandLine_runner.o) was reduced from 3.3 kB to 2.4 kB (stripped).

    A new header, unity_runner_common.h, contains the implementation of UnityRunner_RunTest. This header is included in each generated test runner, so users shouldn't need to do anything with the new header directly.

    The :framework option is no longer supported. I don't think that setting this to anything besides "unity" would have worked anyway. The generated test runners use functions in unity.h, so they need to include unity.h. All other changes should not affect existing usage.

    opened by jlindgren90 11
  • TEST_ASSERT_EQUAL with logical behavior

    TEST_ASSERT_EQUAL with logical behavior

    Currently TEST_ASSERT_EQUAL relays to TEST_ASSERT_EQUAL_INT and casts the variables to compare to INT. This can lead to unexpected behavior whereas it should really just be the opposite of TEST_ASSERT_NOT_EQUAL

    opened by schulz-m 11
  • UnityPrint alternative with printf like formatting

    UnityPrint alternative with printf like formatting

    Concept

    I would like to use printf like formatting to add additional messages to my test output. To do this I propose a function which builds a string using snprintf, and passes it to UnityPrint. The proposed function name is UnityPrintf.

    Possible Implementation

    UnityPrintf(. . .)
    {
        char * logLine;
        logLine = calloc(UNITY_PRINTF_MAX_LEN * sizeof(char));
        snprintf(logLine, UNITY_PRINTF_MAX_LEN, . . .);
        UnityPrint(logLine);
        free(logLine);
    }
    

    snprintf is chosen for avoiding buffer overflow issues. A define will be made with a default of maximum 160 characters, and defined in unity_internals.h inside of a check to see if the define already has been made. If a user wants more or less characters as their max log output, they should override the define by specifying it earlier.

    • [ ] Create UnityPrintf function.
    • [ ] Add define for the maximum line length.

    Does anyone else think this would be useful? I am just using a macro for now.

    opened by kykrueger 10
  • Unity test testHexPrintsUpToMaxNumberOfNibbles() fails on TI C55x

    Unity test testHexPrintsUpToMaxNumberOfNibbles() fails on TI C55x

    This is the test:

    void testHexPrintsUpToMaxNumberOfNibbles(void)
    {
    #ifndef USING_OUTPUT_SPY
        TEST_IGNORE();
    #else
        startPutcharSpy();
        UnityPrintNumberHex(0xBEE, 21);
        endPutcharSpy();
        TEST_ASSERT_EQUAL_INT(sizeof(UNITY_INT)*2, strlen(getBufferPutcharSpy()));
    #endif
    }
    

    On TI, we have:

    • UNITY_MAX_NIBBLES == 8
    • UNITY_INT_WIDTH == 16
    • sizeof(UNITY_INT) == 1
    • actual strlen: 8
    • expected: 4

    So, fail.

    For comparison, on an amd64 PC we have:

    • UNITY_MAX_NIBBLES == 16
    • UNITY_INT_WIDTH == 64
    • sizeof(UNITY_INT) == 8
    • actual strlen: 16
    • expected: 16

    Pass.

    I cannot figure out how to make this test pass consistently on all platforms without introducing a dependency on CHAR_BIT ie. limits.h.

    opened by detly 9
  • Passing safe_level with the 2nd argument of ERB.new is deprecated

    Passing safe_level with the 2nd argument of ERB.new is deprecated

    I am getting this warning when trying to generate test runners:

    ...unity-src/auto/generate_test_runner.rb:344: warning: Passing safe_level with the 2nd argument of ERB.new is deprecated. Do not use it, and specify other arguments as keyword arguments.
    

    Ruby version:

    ruby --version
    ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x64-mingw-ucrt]
    

    Is there a plan to update generate_test_runner.rb and get rid of the deprecated function/usage?

    opened by rhobison 0
  • Bug: invalid filename given when assert fails in included subfile

    Bug: invalid filename given when assert fails in included subfile

    /* Test.cpp */
    #include <unity.h>
    #include "functions.h"
    
    void test_something_specific_to_this_test_file_ok() {
        TEST_ASSERT_TRUE(true);
    }
    
    void test_something_specific_to_this_test_file_fail() {
        TEST_ASSERT_TRUE(false); // line 10
    }
    
    int main() {
        UNITY_BEGIN();
    
        RUN_TEST(test_something_specific_to_this_test_file_ok); // line 16
        RUN_TEST(test_something_specific_to_this_test_file_fail); // line 17
    
        RUN_TEST(test_something_more_universal_from_the_other_file); // line 19
    
        return UNITY_END();
    }
    
    /* functions.h */
    #include <unity.h>
    
    void test_something_more_universal_from_the_other_file() {
        TEST_ASSERT_TRUE(false); // line 5
    }
    

    The result I get:

    Building...
    Testing...
    test/native/test_including/Test.cpp:16: test_something_specific_to_this_test_file_ok	[PASSED]
    test/native/test_including/Test.cpp:10: test_something_specific_to_this_test_file_fail: Expected TRUE Was FALSE	[FAILED]
    test/native/test_including/Test.cpp:5: test_something_more_universal_from_the_other_file: Expected TRUE Was FALSE	[FAILED]
    
    Program received signal SIGINT (Interrupt: 2)
    ----------- native:native/test_including [ERRORED] Took 2.93 seconds -----------
    

    For the last test, the line given 5 is OK, but the filename is wrong: Test.cpp – in reality, the assert that failed is in the functions.h file.

    And that makes debugging confusing and hard.

    opened by MacDada 13
  • Unifying TEST_RANGE & TEST_CASE params

    Unifying TEST_RANGE & TEST_CASE params

    Adding possibility for passing params to TEST_RANGE without any brackets, that will operate as usual TEST_CASE params.

    It will be helpful for implementing param tests with partial params as ranges, partial params as usual values.

    For example:

    TEST_RANGE("example string value", [20, 40, 4])
    void test_unifiedArgs(const char* s, int i)
    {
      // test logic
    }
    

    expected to be equal to usual TEST_CASE cases:

    TEST_CASE("example string value", 20)
    TEST_CASE("example string value", 24)
    TEST_CASE("example string value", 28)
    TEST_CASE("example string value", 32)
    TEST_CASE("example string value", 36)
    TEST_CASE("example string value", 40)
    void test_unifiedArgs(const char* s, int i)
    {
      // test logic
    }
    
    opened by AJIOB 1
  • Add new test result: ERROR

    Add new test result: ERROR

    Sometimes it would be useful to indicate that a test failed before even reaching its test focus. JUnit-like test framework have a dedicated test result for this: ERROR.

    Would it be possible to add this to Unity? Something like "TEST_ERROR()" and "TEST_ERROR_MESSAGE()".

    opened by jauernim 1
  • Add TEST_ASSERT_WITHIN_DOUBLE_ARRAY

    Add TEST_ASSERT_WITHIN_DOUBLE_ARRAY

    Currently unity supports, TEST_ASSERT_EQUAL_DOUBLE_ARRAY. In most cases, it's not helpful to do equality checks on floating point numbers, since a very small rounding error could result in a failed test. It would be much more helpful to implement TEST_ASSERT_EQUAL_DOUBLE_ARRAY, which would allow the check to be done within a certain range of the expected value or even, better yet, to have a way to do the check within a certain percentage of the expected value. Please consider adding this as a feature for double-precision and/or single-precision values.

    opened by jonathon-generac 0
Releases(v2.5.2)
  • v2.5.2(Jan 29, 2021)

  • v2.5.1(May 3, 2020)

  • v2.5.0(Oct 30, 2019)

    It's been a LONG time since the last release of Unity. Finally, here it is!

    There are too many updates to list here, so some highlights:

    • more standards compliant (without giving up on supporting ALL compilers, no matter how quirky)
    • many more specialized assertions for better test feedback
    • more examples for integrating into your world
    • many many bugfixes and tweaks
    Source code(tar.gz)
    Source code(zip)
  • v2.4.3(Nov 14, 2017)

    • Allow suiteSetUp() and suiteTearDown() to be povided as normal C functions
    • Fix & Expand Greater Than / Less Than assertions for integers
    • Built-in option to colorize test results
    • Documentation updates
    Source code(tar.gz)
    Source code(zip)
  • v2.4.2(Sep 12, 2017)

    • Fixed bug in UNTY_TEST_ASSERT_EACH_EQUAL_*
    • Added TEST_ASSERT_GREATER_THAN and TEST_ASSERT_LESS_THAN
    • Updated Module Generator to stop changing names when no style given
    • Cleanup to custom float printing for accuracy
    • Cleanup incorrect line numbers are partial name matching
    • Reduce warnings from using popular function names as variable names
    Source code(tar.gz)
    Source code(zip)
  • v2.4.1(Apr 25, 2017)

    • test runner generator can inject defines as well as headers
    • added a built-in floating point print routine instead of relying on printf
    • updated to new coding and naming standard
    • updated documentation to be markdown instead of pdf
    • fixed many many little bugs, most of which were supplied by the community (you people are awesome!)
    • coding standard actually enforced in CI
    Source code(tar.gz)
    Source code(zip)
  • v2.4.0(Oct 28, 2016)

Owner
Throw The Switch
C Code That Doesn't Suck
Throw The Switch
CppUTest unit testing and mocking framework for C/C++

CppUTest CppUTest unit testing and mocking framework for C/C++ More information on the project page Slack channel: Join if link not expired Getting St

CppUTest 1.1k Dec 26, 2022
Minimal unit testing framework for C

MinUnit Minunit is a minimal unit testing framework for C/C++ self-contained in a single header file. It provides a way to define and configure test s

David Siñuela Pastor 455 Dec 19, 2022
A lightweight unit testing framework for C++

Maintenance of UnitTest++, recently sporadic, is officially on hiatus until 26 November 2020. Subscribe to https://github.com/unittest-cpp/unittest-cp

UnitTest++ 510 Jan 1, 2023
🧪 single header unit testing framework for C and C++

?? utest.h A simple one header solution to unit testing for C/C++. Usage Just #include "utest.h" in your code! The current supported platforms are Lin

Neil Henning 560 Jan 1, 2023
UT: C++20 μ(micro)/Unit Testing Framework

"If you liked it then you "should have put a"_test on it", Beyonce rule [Boost::ext].UT / μt | Motivation | Quick Start | Overview | Tutorial | Exampl

boost::ext 950 Dec 29, 2022
A modern, C++-native, header-only, test framework for unit-tests, TDD and BDD - using C++11, C++14, C++17 and later (or C++03 on the Catch1.x branch)

Catch2 v3 is being developed! You are on the devel branch, where the next major version, v3, of Catch2 is being developed. As it is a significant rewo

Catch Org 16k Jan 8, 2023
A modern, C++-native, header-only, test framework for unit-tests, TDD and BDD - using C++11, C++14, C++17 and later (or C++03 on the Catch1.x branch)

Catch2 v3 is being developed! You are on the devel branch, where the next major version, v3, of Catch2 is being developed. As it is a significant rewo

Catch Org 16k Jan 8, 2023
The fastest feature-rich C++11/14/17/20 single-header testing framework

master branch Windows All dev branch Windows All doctest is a new C++ testing framework but is by far the fastest both in compile times (by orders of

Viktor Kirilov 4.5k Jan 5, 2023
A testing micro framework for creating function test doubles

Fake Function Framework (fff) A Fake Function Framework for C Hello Fake World! Capturing Arguments Return Values Resetting a Fake Call History Defaul

Mike Long 551 Dec 29, 2022
Googletest - Google Testing and Mocking Framework

GoogleTest OSS Builds Status Announcements Release 1.10.x Release 1.10.x is now available. Coming Soon Post 1.10.x googletest will follow Abseil Live

Google 28.7k Jan 7, 2023
A simple C++ 03/11/etc timer class for ~microsecond-precision cross-platform benchmarking. The implementation is as limited and as simple as possible to create the lowest amount of overhead.

plf_nanotimer A simple C++ 03/11/etc timer class for ~microsecond-precision cross-platform benchmarking. The implementation is as limited and simple a

Matt Bentley 102 Dec 4, 2022
Simple Android ARM&ARM64 GOT Hook

Simple Android ARM&ARM64 GOT Hook 基于链接视图和执行视图,解析ELF,查找导入函数偏移值,替换函数地址。 详见:简易Android ARM&ARM64 GOT Hook (一) 简易Android ARM&ARM64 GOT Hook (二) 编译 使用Androi

Xhy 25 Dec 28, 2022
A simple D3D11 Hook for x64 and x86 games. This project is ready to compile (x64 or x86).

D3D11Hook Features: Good Performance Simple, clean, GUI. Rendering using ImGui Clean code Easy to use with another project C++ 17 Xor String Ready to

null 19 Nov 10, 2022
A simple framework for compile-time benchmarks

Metabench A simple framework for compile-time microbenchmarks Overview Metabench is a single, self-contained CMake module making it easy to create com

Louis Dionne 162 Dec 10, 2022
C++ Unit Testing Easier: A Header-only C++ unit testing framework

CUTE C++ Unit Testing Easier: A Header-only C++ unit testing framework usually available as part of the Cevelop C++ IDE (http://cevelop.com) Dependenc

Peter Sommerlad 36 Dec 26, 2022
Simple Unit Testing for C

Unity Test Copyright (c) 2007 - 2021 Unity Project by Mike Karlesky, Mark VanderVoord, and Greg Williams Welcome to the Unity Test Project, one of the

Throw The Switch 2.8k Jan 5, 2023
A unit testing framework for C

Check Table of Contents About Installing Linking Packaging About Check is a unit testing framework for C. It features a simple interface for defining

null 926 Jan 2, 2023
CppUTest unit testing and mocking framework for C/C++

CppUTest CppUTest unit testing and mocking framework for C/C++ More information on the project page Slack channel: Join if link not expired Getting St

CppUTest 1.1k Dec 26, 2022
Minimal unit testing framework for C

MinUnit Minunit is a minimal unit testing framework for C/C++ self-contained in a single header file. It provides a way to define and configure test s

David Siñuela Pastor 455 Dec 19, 2022
A lightweight unit testing framework for C++

Maintenance of UnitTest++, recently sporadic, is officially on hiatus until 26 November 2020. Subscribe to https://github.com/unittest-cpp/unittest-cp

UnitTest++ 510 Jan 1, 2023