How are the docs generated (i.e., the pdf and odt)? I have some grammatical/typos to fix in them but don't know what the source for them is, or how to build them.

thank you for this great unit testing framework.
I am currently evaluating memory leak detection as part of unit testing. You stated in 2011 that unity does not support this:
http://throwtheswitch.squarespace.com/white-papers/comparing-unit-test-frameworks.html

I just wanted to double check if this is still the case or if there is some workaround.

Our builds were previously MS Windows shell only. I've been adapting our test framework to work under cygwin, and I ran into problems where generate_test_runner.rb was parsing a C file that had the degree symbol <0xB0> in line comments. The following error was generated:
../framework/unity/auto/generate_test_runner.rb:76:in gsub': invalid byte sequence in UTF-8 (ArgumentError) from ../framework/unity/auto/generate_test_runner.rb:76:infind_tests'
from ../framework/unity/auto/generate_test_runner.rb:42:in block in run' from ../framework/unity/auto/generate_test_runner.rb:41:inopen'
from ../framework/unity/auto/generate_test_runner.rb:41:in run' from ../framework/unity/auto/generate_test_runner.rb:308:in

Some unit test frameworks allows you to build a test runner that comprises several test modules (suites/test cases/groups) and creates one binary. Is this possible in Unity? The generate_test_runner.rb script accepts only one test file.

Example:

TEST_ASSERT_EQUAL_UINT8( 0xFFU, 0x01U );

Gives output:
:FAIL: Expected 4294967295 Was 1
I expected it to be:
:FAIL: Expected 255 Was 1

The solution is to use the correct display style in unity_internals.h:

#define UNITY_TEST_ASSERT_EQUAL_UINT8(expected, actual, line, message)                           UnityAssertEqualNumber((_U_SINT)(_US8 )(expected), (_U_SINT)(_US8 )(actual), (message), (UNITY_LINE_TYPE)line, UNITY_DISPLAY_STYLE_UINT8)
#define UNITY_TEST_ASSERT_EQUAL_UINT16(expected, actual, line, message)                          UnityAssertEqualNumber((_U_SINT)(_US16)(expected), (_U_SINT)(_US16)(actual), (message), (UNITY_LINE_TYPE)line, UNITY_DISPLAY_STYLE_UINT16)
#define UNITY_TEST_ASSERT_EQUAL_UINT32(expected, actual, line, message)                          UnityAssertEqualNumber((_U_SINT)(_US32)(expected), (_U_SINT)(_US32)(actual), (message), (UNITY_LINE_TYPE)line, UNITY_DISPLAY_STYLE_UINT32)

Instead of:

#define UNITY_TEST_ASSERT_EQUAL_UINT8(expected, actual, line, message)                           UnityAssertEqualNumber((_U_SINT)(_US8 )(expected), (_U_SINT)(_US8 )(actual), (message), (UNITY_LINE_TYPE)line, UNITY_DISPLAY_STYLE_UINT)
#define UNITY_TEST_ASSERT_EQUAL_UINT16(expected, actual, line, message)                          UnityAssertEqualNumber((_U_SINT)(_US16)(expected), (_U_SINT)(_US16)(actual), (message), (UNITY_LINE_TYPE)line, UNITY_DISPLAY_STYLE_UINT)
#define UNITY_TEST_ASSERT_EQUAL_UINT32(expected, actual, line, message)                          UnityAssertEqualNumber((_U_SINT)(_US32)(expected), (_U_SINT)(_US32)(actual), (message), (UNITY_LINE_TYPE)line, UNITY_DISPLAY_STYLE_UINT)

Edit: Was a little to fast with the first solution, the one above should fix it
Edit2: The same issue applies to the INT8, INT16 and INT32 versions of the macro.

The file headers state MIT, but the license.txt file is not the standard MIT license.

This might be considered a duplicate of issue #4.

Example:
TEST_ASSERT_EQUAL(42.0f, 0.0f / 0.0f);
This should fail IMHO, but it passes.

The root cause appears to be in UnityAssertFloatsWithin. The NaN is propagated through to the local variable diff. As NaN is unordered the condition (pos_delta < diff) is always false, so the test passes.

This is a very useful feature that I've come across in GoogleTest (using the --gtest-shuffle option). The main reason you'd want to shuffle tests is to expose any tests that depend on any other test in any way.

I can't use GoogleTest on the embedded target I am working on because it is too heavy weight. Would this be a difficult feature to add?

I'll try toying with an implementation on my fork and submit a pull request when it is ready.

Thanks.

Several macros in src/unity_internals.h use float assert functions instead of double assert functions:

#define UNITY_TEST_ASSERT_DOUBLE_IS_INF(actual, line, message)                                   UnityAssertFloatIsInf((_UF)(actual), (message), (UNITY_LINE_TYPE)line)
#define UNITY_TEST_ASSERT_DOUBLE_IS_NEG_INF(actual, line, message)                               UnityAssertFloatIsNegInf((_UF)(actual), (message), (UNITY_LINE_TYPE)line)
#define UNITY_TEST_ASSERT_DOUBLE_IS_NAN(actual, line, message)                                   UnityAssertFloatIsNaN((_UF)(actual), (message), (UNITY_LINE_TYPE)line)

I think these macros should be this way:

#define UNITY_TEST_ASSERT_DOUBLE_IS_INF(actual, line, message)                                   UnityAssertDoubleIsInf((_UD)(actual), (message), (UNITY_LINE_TYPE)line)
#define UNITY_TEST_ASSERT_DOUBLE_IS_NEG_INF(actual, line, message)                               UnityAssertDoubleIsNegInf((_UD)(actual), (message), (UNITY_LINE_TYPE)line)
#define UNITY_TEST_ASSERT_DOUBLE_IS_NAN(actual, line, message)                                   UnityAssertDoubleIsNaN((_UD)(actual), (message), (UNITY_LINE_TYPE)line)

Also, this macro

#define UNITY_TEST_ASSERT_EQUAL_DOUBLE(expected, actual, line, message)                          UNITY_TEST_ASSERT_DOUBLE_WITHIN((_UF)(expected) * (_UD)UNITY_DOUBLE_PRECISION, (_UD)expected, (_UD)actual, (UNITY_LINE_TYPE)line, message)

should be

#define UNITY_TEST_ASSERT_EQUAL_DOUBLE(expected, actual, line, message)                          UNITY_TEST_ASSERT_DOUBLE_WITHIN((_UD)(expected) * (_UD)UNITY_DOUBLE_PRECISION, (_UD)expected, (_UD)actual, (UNITY_LINE_TYPE)line, message)

(type _UF -> _UD)

I would like to provide patch and pull request but had already forked Unity and changed it too much. I tried to make a second fork of the repository but github does not allow me, and I don't know how to provide a patch.

I see this has been an issue earlier, but for armcc I still get warnings:

"\path\to\unity.c", line 659: Warning:  #222-D: floating-point operation result is out of range
              is_trait = ((1.0f / f_zero) == actual) ? 1 : 0;
                                ^

In addition to L659, there is one for L663, and two for L675.

Not really sure what would be the right fix for it.

When printing out the test file name, path separators should be double slash, otherwise a tab (or other codes) appears in this example:

UnityBegin("my_tests\test.c");

Hacked generate_test_runner.rb with:

filename_slash = filename.dup;
output.puts(" UnityBegin("#{filename_slash.gsub!("", "\")}");")

The unity_fixture_Spy for its unit tests should use the platform-agnostic macros for memory, UNITY_FIXTURE_MALLOC(), and printing, UNITY_OUTPUT_CHAR().

unity_fixture_Test.c:125:5: error: too many arguments to function 'UnityPointer_Init'
Compiled with gcc 4.8.3 under cygwin with makefile from Test Driven Development for Embedded C book.

A major issue we have with tests written with Unity, is that it throws a lot of compiler warnings on GCC and also with static analysis tools such as PC-Lint.

Here's an example error thrown by PC-Lint -

call to function 'TEST_Init_GROUP_RUNNER_runAll()' not made in the presence of a prototype

'TEST_TestGroup_ExampleTestCase_run()' not made in the presence of a prototype

Another issue found by PC-Lint is with the below function in unity_internals.h/.c. It complains of 'Suspicious pointer-to-pointer conversion (area too small)' when a UINT8, UINT16 or INT8, INT16 arrays are passed to this function using 'UNITY_TEST_ASSERT_EQUAL_INT8_ARRAY' and friends.

void UnityAssertEqualIntArray(const _U_SINT* expected,
const _U_SINT* actual,
const _UU32 num_elements,
const char* msg,
const UNITY_LINE_TYPE lineNumber,
const UNITY_DISPLAY_STYLE_T style);

This can be fixed by casting it to a void * pointer instead of a U_SINT* pointer.

Can we do something about these errors and make Unity static analysis (and maximum compiler warning) friendly?

buggy line in unity_fixture.h causes error when FAIL("test error message") is invoked in source file:

define FAIL(message) TEST_FAIL((message))

fix:

define FAIL(message) TEST_FAIL_MESSAGE((message))

When I run 'rake' in extras/fixture, I get the following error:

rake aborted!
No such file or directory - /home/malsyned/projects/tdd-embedded/Unity.playground/extras/fixture/../../targets/gcc.yml

If I fix this error by changing DEFAULT_CONFIG_FILE in rakefile.rb from gcc.yml to gcc_32.yml, I move past that point but get a different failure:

gcc: ../../src/Unity.c: No such file or directory
gcc: no input files
rake aborted!

This turns out to be a capitalization issue - unity.c is all lower-case but the rakefile refers to capital 'U' Unity.c I fixed this by editing rakefile_helper.rb and modifying line 151 to read
src_files << '../../src/Unity.c'

But it still doesn't build!

/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../lib/crt1.o: In function _start': (.text+0x18): undefined reference tomain'
collect2: ld returned 1 exit status
rake aborted!

This final failure, I fixed by adding the following after line 150:
src_files += Dir[HERE+'test/main/*.c']

This is with Unity b7d9d00

When I compiling the most recent unity.c under GCC w/ -Wall I get the following error:

../../src/unity.c:17:8: error: missing braces around initializer [-Werror=missing-braces]
struct _Unity Unity = { 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , {0} };
^
../../src/unity.c:17:8: error: (near initialization for 'Unity.AbortFrame[0]') [-Werror=missing-braces]

Changing this line to

struct _Unity Unity = { 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , {{{0}}} };

clears this error.

float const expected = 1.0f/0.0f;
TEST_ASSERT_EQUAL_FLOAT(expected, 12345.0f); // <-- this will always pass
TEST_ASSERT(expected == 12345.0f); // <-- this will fail

The cause is in unity_internals.h:

define UNITY_TEST_ASSERT_EQUAL_FLOAT(expected, actual, line, message) UNITY_TEST_ASSERT_FLOAT_WITHIN((_UF)(expected) * (_UF)UNITY_FLOAT_PRECISION, (_UF)expected, (_UF)actual, (UNITY_LINE_TYPE)line, message)

Specifically: (_UF)(expected) * (_UF)UNITY_FLOAT_PRECISION
as 1.#INF00 * UNITY_FLOAT_PRECISION still equals 1.#INF00

So we end up checking that our value equals infinity plus or minus infinity.

The runner generation script creates the runner's C code with various puts statements.

I've had to adapt the runner in several projects i.e. to allow coverage measurement retrieval in embedded devices etc. and I have also had to hand over maintenance to people with little knowledge of Ruby.

In both cases using a template for the runner code has proven a much more effective alternative. To this effect I've written a runner generator that uses an ERB template.

The whole thing is up on damphyr/bare_unity.

It's stripped down to only what I have been using (so no plugins or ordered execution etc.)

It also is significantly less Ruby code than the original runner (but that's also due to the omission of some features). It should be easy to add the missing functionality in case you are interested

Unity will call the setUp() function for an ignored test but not the tearDown() function. This is something that you would not expect... The tearDown() should be called for ignored tests as well.

The new UnityBegin function which clears whole struct Unity also clears Unity.TestFile pointer. As a consequence the test file name is not printed while executing tests.

This may be repaired by changing order of following operators in auto/generate_test_runner.rb:

now:
output.puts(" Unity.TestFile = "#{filename}";")
output.puts(" UnityBegin();")
should be:
output.puts(" UnityBegin();")
output.puts(" Unity.TestFile = "#{filename}";")

https://github.com/jwalkerbg60/Unity
commit acc70ad

Sometimes I want to sweep a function under test with a range of values that stress it. Initially, I start by adding a TEST_CASE() macro before the test as described in the documentation and works fine, but overtime I am ending up with several TEST_CASE() macros. What I am proposing is that TEST_CASE-like macro takes a range of values that are passed to the test function.

TEST_RANGE( [ 11, 20, 1 ], [ 0.0, 5.0, 0.5] );
void test_foo(int a, float b)
{
   /* your standard test goes here */
};

Where the TEST_RANGE() macro will take the following entries per array item:
arg1 => start range
arg2 => stop range
arg3 => the increment unit

So the following example:

TEST_RANGE( [ 1, 3, 1 ], [ 0.0, 2.0, 1.0] );

Will create two nested loops, the top loop start with a value equal to 1 and increments by 1 until reach 3, while the inner loop starts with a value of 0.0 and increments by 1.0 until reach 2.0.

The declaration is similar as TEST_CASE(), for example:

#define  TEST_RANGE(...)

Translated the above example into sudo-ruby, we get:

range_int = 0
while range_int <= 3  do # 1st argument
    range_float = 0.0
    while range_float <= 2.0 do # 2nd argument
         output.puts("RUN_TEST( test_foo, line_number, range_int, range_float );")
         range_float += 1.0
    end
    range_int += 1
end

In the runner we will end-up with the following familiar structure:

    ...
    RUN_TEST( test_foo, range_int, <line_number>, 0, 0.0 )
    RUN_TEST( test_foo, range_int, <line_number>, 0, 1.0 )
    RUN_TEST( test_foo, range_int, <line_number>, 0, 2.0 )
    RUN_TEST( test_foo, range_int, <line_number>, 1, 0.0 )
    RUN_TEST( test_foo, range_int, <line_number>, 1, 1.0 )
    RUN_TEST( test_foo, range_int, <line_number>, 1, 2.0 )
    RUN_TEST( test_foo, range_int, <line_number>, 2, 0.0 )
    RUN_TEST( test_foo, range_int, <line_number>, 2, 1.0 )
    RUN_TEST( test_foo, range_int, <line_number>, 2, 2.0 )
    RUN_TEST( test_foo, range_int, <line_number>, 3, 0.0 )
    RUN_TEST( test_foo, range_int, <line_number>, 3, 1.0 )
    RUN_TEST( test_foo, range_int, <line_number>, 3, 2.0 )
    ...

After working with unity for a while I am seeing that some of my test are not covering all the cases that I should. So this request is to include some sort of code coverage infrastructure in Untiy.

I don't have any specifics about how to implement this feature, but what I have seem in the web --wikipedia mainly, by searching for code coverage-- is some sort of file transformation on the fly to get an instrumented version of the file that you want to analyze, then run through your unit test harness, or some sort of this variation.

I just noticed that the test file names do not appear in test reports. After looking into the code, I found this:

void UnityBegin(void)
{
Unity.TestFile = NULL; /** This line should be removed */
Unity.CurrentTestName = NULL;
Unity.CurrentTestLineNumber = 0;
Unity.NumberOfTests = 0;
Unity.TestFailures = 0;
Unity.TestIgnores = 0;
Unity.CurrentTestFailed = 0;
Unity.CurrentTestIgnored = 0;
}

The generated runners first set Unity.TestFile and then call UnityBegin which resets the value.

int main(void)
{
Unity.TestFile = "my_tests.c";
UnityBegin();

...
}

Using Visual Studio 2008 Express Edition, I get:

unity\src\unity.c(610) : error C2124: divide or mod by zero

The line:

if ((1.0f / 0.0f) != actual)

Could Unity use isnan from math.h instead?

I typically develop on VC++, get all tests passing, retest on a PIC24 with the simulator, then run tests on the actual hardware, hence my interest in VC++ compatibility.

The reason that TEST_ASSERT_xyz_WITHIN_MESSAGE() family of functions doesn't print any message is because is calling a re-use macro from the TEST_ASSERT_xyz_WITHIN() family of functions. Let me explain:

TEST_ASSERT_INT_WITHIN() => calls => UNITY_TEST_ASSERT_INT_WITHIN()

TEST_ASSERT_INT_WITHIN_MESSAGE() => calls => UNITY_TEST_ASSERT_INT_WITHIN()

Due this two functions in unity.h calls the same function from unity_internals.h, the message is nullified at this point as follow:

UNITY_TEST_ASSERT_INT_WITHIN(delta, expected, actual, line, message)                     UnityAssertNumbersWithin((_U_SINT)(delta), (_U_SINT)(expected), (_U_SINT)(actual), NULL, (UNITY_LINE_TYPE)line, UNITY_DISPLAY_STYLE_INT)

The issue is in the 4th argument of UnityAssertNumbersWithin() function that has a NULL.

Looks like the linker isn't seeing the weak attributes.

Below, see my command line, and the error message.

$ clang --version
clang version 3.5.0 (217039)
Target: i686-pc-windows-gnu
Thread model: posix

$ clang -target i686-w64-mingw32 -Wall -std=c99 -g -I src -I Unity/src -DUNITY_SUPPORT_64 src/*.c test/*.c Unity/src/*.c -o test_runner
...\Local\Temp\unity-74b0ac.o:.../Unity/src/unity.c:1105: multiple definition of `setUp'
...\Local\Temp\test_xxx-702fc1.o:.../test/test_xxx.c:43: first defined here
...\Local\Temp\unity-74b0ac.o:.../Unity/src/unity.c:1106: multiple definition of `tearDown'
...\Local\Temp\test_xxx-702fc1.o:.../test/test_xxx.c:49: first defined here
collect2.exe: error: ld returned 1 exit status
clang.exe: error: linker (via gcc) command failed with exit code 1 (use -v to see invocation)

The problem goes away if I comment out the definitions of UNITY_SUPPORT_WEAK in unity_internals.h.

On Mac OS X, there is no problem.

I can see three options:

1. Change unity_internals.h to not enable weak linkage if both __WIN32__ and __clang__ are defined. I can't find a generic "Windows" macro, only Win32. So, this would only solve the problem I'm seeing right now, and might not work in other cases. Also, it may mean Unity never uses weak linkage even if future versions of the compiler toolchain allows "weak."
2. Provide a way to opt out of using weak linkage with a preprocessor symbol. That way, someone could add -DUNITY_NO_WEAK to the compiler options to work around the issue. This would require a change to unity_internals.h as well.
3. Take out "weak" and require all users to define setUp() and tearDown().

I've got all three of these coded up and can issue a pull request. Thought I'd get feedback on which option is preferable before doing that, though. (I'm leaning towards options 2 or 3.)

function "UnityIgnoreTest" (defined in unity_fixture.c) misses to count up "Unity.TestIgnores". This then lead to the test result showing "0 Ignored" when it should show "1 Ignored".

I guessed the fix for this bug to be adding "Unity.TestIgnores++;" in function "UnityIgnoreTest()" This function would then look like this:

void UnityIgnoreTest()
{
    Unity.NumberOfTests++;
    Unity.TestIgnores++;
    Unity.CurrentTestIgnored = 1;
    UNITY_OUTPUT_CHAR('!');
}

But after adding another TEST case (not an ignored one), the Ignore count showed 2! Then playing around a little bit showed that the problem seems to face up only if the ignored test case is the last in the group (TEST_GROUP_RUNNER)!

I now definitively know there is a bug, but my proposed solution above is not valid.

Unity needs a TEST_ASSERT to verify that every element of an array is equal to a single value.

Simple example: I want to test that my memset function properly sets a range of bytes equal to a particular value.

TEST_ASSERT_EQUAL_MEMORY compares two blocks of memory, but I want to compare one block of memory to a single value.

You could call TEST_ASSERT_EQUAL in a loop over each byte (or element of the actual array) but this doesn't provide any indication as to which element failed.

Currently, to emulate this, one needs to construct an expected array, and then use TEST_ASSERT_EQUAL_MEMORY to verify that they are equal.

(I already submitted this via email, but wanted to track it on GitHub, as I may get time to implement this.)

The Unity Fixture overrides the standard library memory management functions like malloc() and free() with it's own functions that track leaks and allow failure injection. For systems that use the standard library this works great but for embedded systems using a custom heap, such as the one included with FreeRTOS, it makes compilation for the Unity Fixture a real pain.

It'd be great if there were Unity Fixture-specific memory management functions doing the actual heap work that could be overridden in unity_config.h.

Since the unity_fixture format is different from unity it will not work with parseOutput.rb for generating XML. Is this something that is planned to be fixed? (Haven't seen a lot of activity in the fixture directory.)

Hi,
I've encountered some issue by testing my code, I got some function which definition looks like this :

typedef enum
{
    AAA,
    BBB,
    CCC
} TEST_error_t ;

TEST_error_t TEST_fnc(void)
{
  return AAA ; 
}

Then in my test I'm trying to test value which returns the TEST_fnc() by invoking following code:

TEST_ASSERT_EQUAL(AAA,TEST_fnc()) ;

GCC throws me a warning then that :

cast from function call of type ‘TEST_error_t’ to non-matching type ‘long long int’

,when I'm testing return value from the function like this, warning disappears

TEST_error_t ret = TEST_fnc() ;
TEST_ASSERT_EQUAL(AAA,ret) ;

I'm working on the 64-bit system, could you please tell am I doing something wrong ?

If I git clone unity and then make, I get an error due to the fact that there's no build directory.
build is in .gitignore but is required to be present in order for make to run so that build/testunity_Runner.c can be created.

Output:

andrew@brick:~/git/unity$ make
rm -f build/*.o ; rm -f testunity.out
ruby auto/generate_test_runner.rb test/testunity.c build/testunity_Runner.c
auto/generate_test_runner.rb:58:in `initialize': No such file or directory - build/testunity_Runner.c (Errno::ENOENT)
    from auto/generate_test_runner.rb:58:in `open'
    from auto/generate_test_runner.rb:58:in `generate'
    from auto/generate_test_runner.rb:48:in `run'
    from auto/generate_test_runner.rb:315:in `<main>'
make: *** [default] Error 1

andrew@brick:~/git/unity$ mkdir build

andrew@brick:~/git/unity$ make
rm -f build/*.o ; rm -f testunity.out
ruby auto/generate_test_runner.rb test/testunity.c build/testunity_Runner.c
gcc -Isrc -DTEST -DUNITY_SUPPORT_64 src/unity.c test/testunity.c build/testunity_Runner.c -o testunity.out
testunity.out
make: testunity.out: Command not found
make: *** [default] Error 127

andrew@brick:~/git/unity$ ls build
testunity_Runner.c

The make: testunity.out: Command not found error is documented in bug #15.

When compiling with gcc 4.8.3 under cygwin:
unity_fixture.c:15:26: error: 'putchar' undeclared here (not in a function)
Solved adding #include <stdio.h>

Several of INT* and UINT* macros used UNITY_DISPLAY_STYLE_INT style. I changed this styles to respect integer widths.

jwalkerbg60@378b48c
commit 378b48c

This commit contains changes of >, >=, <=, < comparator macros too. So, if you want these, they are in. If not, you may want to copy only == macros.

Hello,

This afternoon, I was writing a test taht use the TEST_ASSERT_EQUAL_INT32 macro and I encountered a bug that happens when the expected or the actual value is equal to -2147483648 (0x80000000) and the test failed.

Instead of printing the number, the result is "-(". The sign is well printed, but not the number.

I think the bug comes from the following function:

void UnityPrintNumber(const _U_SINT number_to_print)
{
    _U_SINT divisor = 1;
    _U_SINT next_divisor;
    _U_SINT number = number_to_print;

    if (number < 0)
    {
        UNITY_OUTPUT_CHAR('-');
        number = -number;
    }

    // figure out initial divisor
    while (number / divisor > 9)
    {
        next_divisor = divisor * 10;
        if (next_divisor > divisor)
            divisor = next_divisor;
        else
            break;
    }

    // now mod and print, then divide divisor
    do
    {
        UNITY_OUTPUT_CHAR((char)('0' + (number / divisor % 10)));
        divisor /= 10;
    }
    while (divisor > 0);
}

Especially when you have the negative number -2147483648 (0x80000000), the following piece of code checks the sign and changes it to positive:

if (number < 0)
{
    UNITY_OUTPUT_CHAR('-');
    number = -number;
}

The problem is that it's not possible to store 0x80000000 as a psotive value in a signed 32-bit variable. The maximum positive value that can be stored is 2^31-1 (0x7FFFFFFF or 2147483647). The variable "number" could be a 64-bit data type, but this is certainly not the best solution since you have to use a 64-bit data even if 64-bit support is disabled.

If it's not a real bug, simply forget my issue.

@+

With a list of 10 tests and the last test set to IGNORE_TEST, the results of the test are not reported properly:

Unity test run 1 of 1

.........!

10 Tests 0 Failures 0 Ignored
OK

The "!" is correct, showing the last test ignored, but the final statistics are incorrect: 10/0/0 for pass/fail/ignore. Should be 10/0/1.

Reversing the order of the final two tests in the test runner yields proper results:

Unity test run 1 of 1

........!.

10 Tests 0 Failures 1 Ignored
OK

Verified that the test is, in fact, ignored by inserting a TEST_FAIL into it. Have also verified that moving other tests into the last position creates the same issue. Issue is limited to the last test in the list.

Running the Unity tests using rake produces a failure the first time I run, followed by success the 2nd time. I'm on Windows 7 64-bit using MinGW, Ruby 1.9.3. The error output: on the first run is below. Running rake again produces all tests passing. The third time produces the error below, etc.

C:\Users\bjones\Documents\micro_book\Unity>rake
rm -r build/testparameterized.exe
rm -r build/testparameterized.o
rm -r build/testparameterized.testpass
rm -r build/testparameterized_Runner.c
rm -r build/testparameterized_Runner.o
rm -r build/testsample_cmd.c
rm -r build/testsample_def.c
rm -r build/testsample_mock_cmd.c
rm -r build/testsample_mock_def.c
rm -r build/testsample_mock_new1.c
rm -r build/testsample_mock_new2.c
rm -r build/testsample_mock_param.c
rm -r build/testsample_mock_run1.c
rm -r build/testsample_mock_run2.c
rm -r build/testsample_mock_yaml.c
rm -r build/testsample_new1.c
rm -r build/testsample_new2.c
rm -r build/testsample_param.c
rm -r build/testsample_run1.c
rm -r build/testsample_run2.c
rm -r build/testsample_yaml.c
rm -r build/testunity.exe
rm -r build/testunity.o
rm -r build/testunity.testpass
rm -r build/testunity_Runner.c
rm -r build/testunity_Runner.o
rm -r build/unity.o
rm -r C:/Users/bjones/Documents/micro_book/Unity/build
C:/Ruby193/bin/ruby.exe -I"lib" -I"C:/Ruby193/lib/ruby/gems/1.9.1/gems/rake-10.0
.2/lib" "C:/Ruby193/lib/ruby/gems/1.9.1/gems/rake-10.0.2/lib/rake/rake_test_load
er.rb" "test/test_*.rb"
Loaded suite C:/Ruby193/lib/ruby/gems/1.9.1/gems/rake-10.0.2/lib/rake/rake_test_
loader
Started
E
===============================================================================
Error: test_ShouldGenerateARunnerByCreatingRunnerWithOptions(TestGenerateTestRun
ner)
  Errno::ENOENT: No such file or directory - build/testsample_def.c
C:/Users/bjones/Documents/micro_book/Unity/auto/generate_test_runner.rb:58:in `i
nitialize'
C:/Users/bjones/Documents/micro_book/Unity/auto/generate_test_runner.rb:58:in `o
pen'
C:/Users/bjones/Documents/micro_book/Unity/auto/generate_test_runner.rb:58:in `g
enerate'
C:/Users/bjones/Documents/micro_book/Unity/auto/generate_test_runner.rb:48:in `r
un'
C:/Users/bjones/Documents/micro_book/Unity/test/test_generate_test_runner.rb:40:
in `block in test_ShouldGenerateARunnerByCreatingRunnerWithOptions'
C:/Users/bjones/Documents/micro_book/Unity/test/test_generate_test_runner.rb:39:
in `each_pair'
C:/Users/bjones/Documents/micro_book/Unity/test/test_generate_test_runner.rb:39:
in `test_ShouldGenerateARunnerByCreatingRunnerWithOptions'
     36:              'new2' => { :plugins => [:ignore], :suite_setup => "a_cust
om_setup();", :suite_teardown => "a_custom_teardown();" }
     37:     }
     38:
  => 39:     sets.each_pair do |subtest, options|
     40:       UnityTestRunnerGenerator.new(options).run(TEST_FILE, OUT_FILE + s
ubtest + '.c')
     41:       verify_output_equal(subtest)
     42:       UnityTestRunnerGenerator.new(options).run(TEST_MOCK, OUT_FILE + '
mock_' + subtest + '.c')
===============================================================================
auto/generate_test_runner.rb:58:in `initialize': No such file or directory - bui
ld/testsample_cmd.c (Errno::ENOENT)
        from auto/generate_test_runner.rb:58:in `open'
        from auto/generate_test_runner.rb:58:in `generate'
        from auto/generate_test_runner.rb:48:in `run'
        from auto/generate_test_runner.rb:315:in `<main>'
E
===============================================================================
Error: test_ShouldGenerateARunnerByPullingCommandlineOptions(TestGenerateTestRun
ner)
  Errno::ENOENT: No such file or directory - build/testsample_cmd.c
C:/Users/bjones/Documents/micro_book/Unity/test/test_generate_test_runner.rb:29:
in `read'
C:/Users/bjones/Documents/micro_book/Unity/test/test_generate_test_runner.rb:29:
in `verify_output_equal'
C:/Users/bjones/Documents/micro_book/Unity/test/test_generate_test_runner.rb:75:
in `test_ShouldGenerateARunnerByPullingCommandlineOptions'
     72:     subtest = 'cmd'
     73:     cmdstr = "ruby auto/generate_test_runner.rb -cexception \"#{TEST_FI
LE}\" \"#{OUT_FILE + subtest + '.c'}\""
     74:     `#{cmdstr}`
  => 75:     verify_output_equal(subtest)
     76:
     77:     cmdstr = "ruby auto/generate_test_runner.rb -cexception \"#{TEST_MO
CK}\" \"#{OUT_FILE + 'mock_' + subtest + '.c'}\""
     78:     `#{cmdstr}`
===============================================================================
auto/generate_test_runner.rb:58:in `initialize': No such file or directory - bui
ld/testsample_yaml.c (Errno::ENOENT)
        from auto/generate_test_runner.rb:58:in `open'
        from auto/generate_test_runner.rb:58:in `generate'
        from auto/generate_test_runner.rb:48:in `run'
        from auto/generate_test_runner.rb:315:in `<main>'
E
===============================================================================
Error: test_ShouldGenerateARunnerByPullingYamlOptions(TestGenerateTestRunner)
  Errno::ENOENT: No such file or directory - build/testsample_yaml.c
C:/Users/bjones/Documents/micro_book/Unity/test/test_generate_test_runner.rb:29:
in `read'
C:/Users/bjones/Documents/micro_book/Unity/test/test_generate_test_runner.rb:29:
in `verify_output_equal'
C:/Users/bjones/Documents/micro_book/Unity/test/test_generate_test_runner.rb:64:
in `test_ShouldGenerateARunnerByPullingYamlOptions'
     61:     subtest = 'yaml'
     62:     cmdstr = "ruby auto/generate_test_runner.rb test/testdata/sample.ym
l \"#{TEST_FILE}\" \"#{OUT_FILE + subtest + '.c'}\""
     63:     `#{cmdstr}`
  => 64:     verify_output_equal(subtest)
     65:
     66:     cmdstr = "ruby auto/generate_test_runner.rb test/testdata/sample.ym
l \"#{TEST_MOCK}\" \"#{OUT_FILE + 'mock_' + subtest + '.c'}\""
     67:     `#{cmdstr}`
===============================================================================
E
===============================================================================
Error: test_ShouldGenerateARunnerByRunningRunnerWithOptions(TestGenerateTestRunn
er)
  Errno::ENOENT: No such file or directory - build/testsample_run1.c
C:/Users/bjones/Documents/micro_book/Unity/auto/generate_test_runner.rb:58:in `i
nitialize'
C:/Users/bjones/Documents/micro_book/Unity/auto/generate_test_runner.rb:58:in `o
pen'
C:/Users/bjones/Documents/micro_book/Unity/auto/generate_test_runner.rb:58:in `g
enerate'
C:/Users/bjones/Documents/micro_book/Unity/auto/generate_test_runner.rb:48:in `r
un'
C:/Users/bjones/Documents/micro_book/Unity/test/test_generate_test_runner.rb:53:
in `block in test_ShouldGenerateARunnerByRunningRunnerWithOptions'
C:/Users/bjones/Documents/micro_book/Unity/test/test_generate_test_runner.rb:52:
in `each_pair'
C:/Users/bjones/Documents/micro_book/Unity/test/test_generate_test_runner.rb:52:
in `test_ShouldGenerateARunnerByRunningRunnerWithOptions'
     49:              'run2' => { :plugins => [:ignore], :suite_setup => "a_cust
om_setup();", :suite_teardown => "a_custom_teardown();" }
     50:     }
     51:
  => 52:     sets.each_pair do |subtest, options|
     53:       UnityTestRunnerGenerator.new.run(TEST_FILE, OUT_FILE + subtest +
'.c', options)
     54:       verify_output_equal(subtest)
     55:       UnityTestRunnerGenerator.new.run(TEST_MOCK, OUT_FILE + 'mock_' +
subtest + '.c', options)
===============================================================================
E
===============================================================================
Error: test_ShouldGenerateARunnerThatUsesParameterizedTests(TestGenerateTestRunn
er)
  Errno::ENOENT: No such file or directory - build/testsample_param.c
C:/Users/bjones/Documents/micro_book/Unity/auto/generate_test_runner.rb:58:in `i
nitialize'
C:/Users/bjones/Documents/micro_book/Unity/auto/generate_test_runner.rb:58:in `o
pen'
C:/Users/bjones/Documents/micro_book/Unity/auto/generate_test_runner.rb:58:in `g
enerate'
C:/Users/bjones/Documents/micro_book/Unity/auto/generate_test_runner.rb:48:in `r
un'
C:/Users/bjones/Documents/micro_book/Unity/test/test_generate_test_runner.rb:87:
in `block in test_ShouldGenerateARunnerThatUsesParameterizedTests'
C:/Users/bjones/Documents/micro_book/Unity/test/test_generate_test_runner.rb:86:
in `each_pair'
C:/Users/bjones/Documents/micro_book/Unity/test/test_generate_test_runner.rb:86:
in `test_ShouldGenerateARunnerThatUsesParameterizedTests'
     83:     sets = { 'param'  => { :plugins => [:ignore], :use_param_tests => t
rue }
     84:     }
     85:
  => 86:     sets.each_pair do |subtest, options|
     87:       UnityTestRunnerGenerator.new(options).run(TEST_FILE, OUT_FILE + s
ubtest + '.c')
     88:       verify_output_equal(subtest)
     89:       UnityTestRunnerGenerator.new(options).run(TEST_MOCK, OUT_FILE + '
mock_' + subtest + '.c')
===============================================================================


Finished in 0.199012 seconds.

5 tests, 0 assertions, 0 failures, 5 errors, 0 pendings, 0 omissions, 0 notifica
tions
0% passed

25.12 tests/s, 0.00 assertions/s
rake aborted!
Command failed with status (1): [ruby -I"lib" -I"C:/Ruby193/lib/ruby/gems/1.9.1/
gems/rake-10.0.2/lib" "C:/Ruby193/lib/ruby/gems/1.9.1/gems/rake-10.0.2/lib/rake/
rake_test_loader.rb" "test/test_*.rb" ]
Tasks: TOP => default => all => scripts
(See full trace by running task with --trace)

This more a remark: in the older versions of unity the test reports were like

...
my_tests.c:4324:test_myfunc_39:PASS
my_tests.c:4342:test_myfunc_40:PASS
...
and with the latest version they now print an additional end of line at the beginning of each test

...
my_tests.c:4324:test_myfunc_39:PASS

my_tests.c:4342:test_myfunc_40:PASS
...

I think we can get rid of the blank line here.
Here is how I did it:

void UnityTestResultsBegin(const char* file, const UNITY_LINE_TYPE line)
{
UNITY_PRINT_EOL; /** Remove this line */
UnityPrint(file);
UNITY_OUTPUT_CHAR(':');
UnityPrintNumber((_U_SINT)line);
UNITY_OUTPUT_CHAR(':');
UnityPrint(Unity.CurrentTestName);
UNITY_OUTPUT_CHAR(':');
}

When i try to run make in the example_2 directory, I get the following error:

gcc -std=c99 -Wall -Wextra -Werror  -Wpointer-arith -Wcast-align -Wwrite-strings -Wswitch-default -Wunreachable-code -Winit-self -Wmissing-field-initializers -Wno-unknown-pragmas -Wstrict-prototypes -Wundef -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -DUNITY_FIXTURES -Isrc -I../../src -I../../extras/fixture/src  ../../src/unity.c ../../extras/fixture/src/unity_fixture.c src/ProductionCode.c src/ProductionCode2.c test/TestProductionCode.c test/TestProductionCode2.c test/test_runners/TestProductionCode_Runner.c test/test_runners/TestProductionCode2_Runner.c test/test_runners/all_tests.c -o all_tests.out
../../src/unity.c:113:6: error: no previous prototype for ‘UnityPrintLen’ [-Werror=missing-prototypes]
 void UnityPrintLen(const char* string, const _UU32 length)
      ^
cc1: all warnings being treated as errors
makefile:66: recipe for target 'default' failed
make: *** [default] Error 1

Steps to reproduce:

• pull the most recent master branch
• cd into the example_2 directory
• run make

gcc -v:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10) 

Clang throws a number of warnings around tests using unity_fixture.h

An example is -
error: no previous extern declaration for non-static variable 'TEST_GROUP_GroupName' [-Werror,-Wmissing-variable-declarations]

It is because the TEST_GROUP() macro declares a global variable that is not used anywhere. I'll have a go at fixing this and submit a pull request.

It seems that failing tests (at least ones due to failing asserts) miss an EOL at the end of the printed line.

This is the output from a sample project, in which the output belonging to the next test is just appended to the output of the previous test case that failed:
TEST(BowlingGame, TestGutter)test/bowlinggame/bowlinggameTest.c:22:TEST(BowlingGame, TestGutter):FAIL: Expected 1 Was 0TEST(BowlingGame, TestAllOnes) PASS

Running make in examples/example_1, example_2, example_3 fails.

Problem occurs directly followng a 'git clone ..'

Two apparent problems, both in the no_ruby/*_Runner.c files:

1. They call 'Unity_Begin' without a filename.
2. RUN_TEST macro seems to be undeclared.

When the 'ruby' calls are uncommented in the makefile then the runners are generated correctly.

This is more like a feature request. It would be nice to have configurable:

1. the "test_" prefix the generator is looking for. Some would like to have it as "tc_" (for test case)
2. "setUp" and "tearDown" names. For example, it would be nice to be able to change it to "test_setup"/"test_teardown" or something else.
3. The names suite_setup and suite_teardown are good ones, and it would be nice to be able to define such functions in your own test_something.c file, and configure yml accordingly. Currently, these names are used in the generated runner, thus, it's impossible to define the same symbols. The generated runner should rather have something like "generated_runner_suite_setup()" and "generated_runner_suite_teardown()" instead, so that it unlikely collides with the user defined functions.

Thanks!

In order to get the examples running (directory examples), I had to modify the makefiles that they pass the "-std=c11" option to gcc C-compiler. Otherwise the RUN_TEST macros are not expanded the way they are actually used.

In the malloc overrides header unity_fixture_malloc_overrides.h, included by unity_fixture.h, the macro names malloc, calloc, realloc, and free are defined. This causes undefined behaviour if <stdlib.h> is included prior to the definition, or included later with the definitions still present (C99 7.1.3p1 and p2, also ANSI C and C11 but I'll use C99 as a reference as it seems to be the most prevalent standard at this time).

Therefore, it should be documented that <stdlib.h> must not be included alongside unity_fixture.h.

On a more practical note, compiling unity_fixture.c with gcc 4.6.3 currently yields the warnings

on x86_64 glibc 2.15. While unity_fixture.c takes care not to include <stdlib.h> before malloc and free are undefined (calloc and realloc seem to have been forgotten), the header <string.h> includes <stdlib.h> somewhere down in its belly. I believe this is a bug in glibc as the inclusion of <string.h> has no business of declaring malloc and friends. Nevertheless, it may be generally difficult for unity users to avoid the inclusion of <stdlib.h> when using unity_fixture.h. Maybe forced malloc failures are better implemented at the dynamic linker level (cf. LD_PRELOAD).

Declaration of functions with an empty list of argument generate the following warning with armcc compiler:
Unity\extras\fixture\src\unity_fixture_internals.h(29): warning: #1295-D: Deprecated declaration UnityMalloc_StartTest - give arg types

The following function declarations are affected:
Line 29: void UnityMalloc_StartTest(void);
Line 30: void UnityMalloc_EndTest(void);
Line 31: int UnityFailureCount(void);
Line 33: void UnityConcludeFixtureTest(void);
Line 36: void UnityPointer_UndoAllSets(void);
Line 37: void UnityPointer_Init(void);

A passing test has "PASS" and finishes with "OK"
A failing test has "FAIL" and finishes with "FAIL"
I propose changing the final "FAIL" to "FAILED", but leaving a failed test as "FAIL"
This means scripts and parsers can more easily detect the end of a run and break out of any polling loops. I am currently working with ARM SWO for in target test result output with a custom SWO parser. The change would dramatically simplify the parsing code.
e.g. from:
Unity test run 1 of 1
TEST(UnityFixture, WillPass) PASS
TEST(UnityFixture, WillFail)../src/tests.c:26:TEST(UnityFixture, WillFail):FAIL: Expected -1 Was 0
TEST(UnityFixture, AnotherPassingTest) PASS
TEST(UnityFixture, IngnoredTest)../src/tests.c:36:TEST(UnityFixture, IngnoredTest):IGNORE: Ignore message

4 Tests 1 Failures 1 Ignored
FAIL

to:

Unity test run 1 of 1
TEST(UnityFixture, WillPass) PASS
TEST(UnityFixture, WillFail)../src/tests.c:26:TEST(UnityFixture, WillFail):FAIL: Expected -1 Was 0
TEST(UnityFixture, AnotherPassingTest) PASS
TEST(UnityFixture, IngnoredTest)../src/tests.c:36:TEST(UnityFixture, IngnoredTest):IGNORE: Ignore message

4 Tests 1 Failures 1 Ignored
FAILED

unity.c:653:5: error: switch missing default case [-Werror=switch-default]
unity.c:813:5: error: switch missing default case [-Werror=switch-default]
Compiled with gcc 4.8.3 under cygwin with makefile from Test Driven Development for Embedded C book and double floats enabled.

What tools do you use for Code Coverage?

thanks