throwtheswitch / unity Goto Github PK
View Code? Open in Web Editor NEWSimple Unit Testing for C
Home Page: ThrowTheSwitch.org
License: MIT License
Simple Unit Testing for C
Home Page: ThrowTheSwitch.org
License: MIT License
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.
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 )
...
This is more like a feature request. It would be nice to have configurable:
Thanks!
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:
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."-DUNITY_NO_WEAK
to the compiler options to work around the issue. This would require a change to unity_internals.h
as well.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.)
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
unity_fixture.c: In function ‘unity_malloc’:
unity_fixture.c:185:5: warning: implicit declaration of function ‘malloc’ [-Wimplicit-function-declaration]
unity_fixture.c:185:21: warning: incompatible implicit declaration of built-in function ‘malloc’ [enabled by default]
unity_fixture.c: In function ‘release_memory’:
unity_fixture.c:208:5: warning: implicit declaration of function ‘free’ [-Wimplicit-function-declaration]
unity_fixture.c:208:5: warning: incompatible implicit declaration of built-in function ‘free’ [enabled by default]
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).
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>
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:in
find_tests'
from ../framework/unity/auto/generate_test_runner.rb:42:in block in run' from ../framework/unity/auto/generate_test_runner.rb:41:in
open'
from ../framework/unity/auto/generate_test_runner.rb:41:in run' from ../framework/unity/auto/generate_test_runner.rb:308:in
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.
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.
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();
...
}
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 to
main'
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
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.
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.
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}";")
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.)
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.
What tools do you use for Code Coverage?
thanks
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.
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:
When the 'ruby' calls are uncommented in the makefile then the runners are generated correctly.
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.
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.
The unity_fixture_Spy for its unit tests should use the platform-agnostic macros for memory, UNITY_FIXTURE_MALLOC()
, and printing, UNITY_OUTPUT_CHAR()
.
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.
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!("", "\")}");")
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)
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.
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.
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.)
buggy line in unity_fixture.h causes error when FAIL("test error message") is invoked in source file:
fix:
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.
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.
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
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
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.
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:
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.
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.
@+
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?
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(':');
}
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
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);
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.
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 ?
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
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:
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)
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.
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.
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.
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.
The file headers state MIT, but the license.txt file is not the standard MIT license.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.