cgreen-users — Users cgreen related matters. Support questions welcome.

[Cgreen-users] Problem with simple example code

[Marc F. <ma...@ba...>]

Hi there

I am new to unit testing (and quite new to C development too), and I'm 
interested in using Cgreen as a UT framework. However when I follow the 
quickstart guide, I'm facing an issue when trying to compile the second 
version of the "first_test.c" example:

/* test.c */
#include "cgreen/cgreen.h"

Ensure(this_test_should_pass) {
     assert_that(1 == 1, is_true);
}

Ensure(this_test_should_fail) {
     assert_that(0, is_equal_to(1));
}

int
main(int argc, char **argv)
{
     TestSuite *suite = create_test_suite();

     add_test(suite, this_test_should_pass);
     add_test(suite, this_test_should_fail);

     return run_test_suite(suite, create_text_reporter());
}

$ gcc -std=gnu99 -Wall -O0 -g -lm -lcgreen -o test test.c
test.c:3:31: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
before ‘{’ token
test.c:7:31: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
before ‘{’ token
test.c: In function ‘main’:
test.c:16:5: error: ‘this_test_should_pass’ undeclared (first use in 
this function)
test.c:16:5: note: each undeclared identifier is reported only once for 
each function it appears in
test.c:17:5: error: ‘this_test_should_fail’ undeclared (first use in 
this function)
make: *** [test2] Error 1

Am I missing something obvious?

Note: the Cgreen library is well installed and functional as the first 
version of the example test works. I'm using the "1.0.0_beta2" version 
with GCC 4.7.2 and Glibc 2.16.0 on GNU/Linux, let me know if you need 
more information on my setup.

Regards,

m.

[Cgreen-users] mock output parameters and custom compare for want()

[Badea D. <bad...@ya...>]

Hi all,

In my application framework all functions are returning error codes. Output data 
is stored using pointers (out parameters). I saw there is a patch done by 
Anthony Lineberry ("patch to add out param support in mocks - ID: 2446504") 
addressing this issue but it's not present in the 1.0.0-beta2 release.
Is there a plan to integrate it in the official release any time soon?
Is there a workaround so i can mock output parameters?

Another issue is with input parameters that are not ints or pointers. Trying to 
pass a structure to mock() results in a compile error. As a workaround I passed 
the address of the structure to mock() but then I realized that there is no 
want_...() variant for arrays.
Is there a want_...() function that accepts a custom compare function?

Thanks,
Daniel Badea


      

[Cgreen-users] cgreen as unit test framework.

[João H. F. <jo...@gm...>]

Hello,

I am search an open source project wich use cgreen as unit test
framework. If you know any, let me see.

Thanks.

-- 
-----------------------------------------------------------
João Henrique Freitas - joaohf_at_gmail.com
Campinas-SP-Brasil
BSD051283
LPI 1
http://www.joaohfreitas.eti.br

Re: [Cgreen-users] [Cgreen-devel] When CGreen runs out of memory

[Marcus B. <ma...@la...>]

Hi...

Andreas Schneider wrote:
> well, cgreen is a library and a library should never call exit().

Why not?

Your assertion is incorrect. CGreen is a tool, not a library. The code
under test is the client code in this case. The most common use case for
a unit tester is that it is testing the low level *parts* of an application.

It can be used to test the whole app., but that is not the primary use
case. The reason for having the tests in the same language as the code
is to facilitate writing low level tests. An application test would
probably have an intermediate shell invocation or whatever the external
interface was.

> The test developer should be able to cleanup his own things!

If they could always do that, they wouldn't need tests now, would they? :)

I did say that this is a tool for people writing their first unit tests.

> And go back to the application :)

The only time this would happen is if CGreen is embedded in something
else. In this case it would have an indirect connection (shell/sockets)
to read the output. I don't think you would want to couple your
IDE/Workbench/CruiseControl to a CGreen crash.

We could add a C level driver API later, but I don't want to do that for
version 1.0. I just want to get the thing out there.

> Cleanup the memory and return a FATAL error to the test application. Use 
> functions with return values instead of void.

The whole point of what I'm saying. I'd prefer not to have a manual
maintenance pain if I can design my way out of it. That stuff died out
last century, because it's damn ugly.

There are OS project reasons for this. I want to fight every last line
of clutter in the top level. If the code is clean, we get more
contributers down the line.

Even if you don't agree, which is fair enough, I am going to be the one
having to maintain everything in 5 years time. Five years of chasing
return codes will really add up. Have a heart.

> Have you ever looked at talloc?

Yes, and obstacks and some other server allocators. It was this stuff I
was thinking of when I posted. I don't want to have an external
dependency on anything other than the C standard library though.
Besides, we don't need anything that complicated. I was just going to
keep a list of things to free().

> 
> Cheers,
> 
> 
> 	-- andreas

yours, Marcus

Re: [Cgreen-users] [Cgreen-devel] When CGreen runs out of memory

[Andreas S. <ma...@cy...>]

On Monday 18 May 2009 19:19:01 Marcus Baker wrote:
> Hi...

Hello,

>
> I'm trying to avoid spraying a whole bunch of NULL checks everywhere. I
> propose that a malloc failure in the CGreen code itself is fatal and we
> jump straight out of our own version of malloc()/realloc().

well, cgreen is a library and a library should never call exit(). It should 
report a fatal error and the application which is using the cgreen library 
should call exit().

The test developer should be able to cleanup his own things!

> 1) In the master process, something is really wrong if malloc() fails.
> It means the test suite and CUT has been grabbing memory and locking it
> into RAM. We print the name of the test suite (so the user knows how far
> they got) and stop the test run.

And go back to the application :)

>
> 2) In a test process, we just bomb the test. There is a problem keeping
> lint and valgrind happy in this case. In bombing out, we have to clean
> everything up. I propose that we use our own versions of malloc() and
> free() when inside tests. Either the exit handler or a longjmp() can be
> used to trigger the cleanup.

Cleanup the memory and return a FATAL error to the test application. Use 
functions with return values instead of void.

> I like the idea of registering unallocated blocks and cleaning them up
> en masse. It gets rid of free() calls in the code and is safer.

Have you ever looked at talloc?

Cheers,


	-- andreas

[Cgreen-users] When CGreen runs out of memory

[Marcus B. <ma...@la...>]

Hi...

I'm trying to avoid spraying a whole bunch of NULL checks everywhere. I
propose that a malloc failure in the CGreen code itself is fatal and we
jump straight out of our own version of malloc()/realloc().

1) In the master process, something is really wrong if malloc() fails.
It means the test suite and CUT has been grabbing memory and locking it
into RAM. We print the name of the test suite (so the user knows how far
they got) and stop the test run.

2) In a test process, we just bomb the test. There is a problem keeping
lint and valgrind happy in this case. In bombing out, we have to clean
everything up. I propose that we use our own versions of malloc() and
free() when inside tests. Either the exit handler or a longjmp() can be
used to trigger the cleanup.

I like the idea of registering unallocated blocks and cleaning them up
en masse. It gets rid of free() calls in the code and is safer.

What do you all think?

yours, Marcus

[Cgreen-users] cgreen beta preparation

[João H. F. <jo...@gm...>]

Hello,

Just to tell you. I am preparing a cgreen beta on sourceforge. More
few days and I am put it there.

Any suggestion and minor fixes are welcome.

Thanks

-- 
-----------------------------------------------------------
João Henrique Freitas - joaohf_at_gmail.com
Campinas-SP-Brasil
BSD051283
LPI 1
http://www.joaohfreitas.eti.br

Re: [Cgreen-users] About collector tool, how to use.

[J. H. F. <jo...@gm...>]

Hello.

Please see the collector.patch

>> How I can use the collector tool?
>
> You can't. I haven't finished it :).
>
> Ideally it's a tool that you can invoke with your IDE. At the moment,
> every time I add a test I forget to add the function to the test suite.
> By invoking this after an edit session I know that everything will get
> realligned.
>
>
> If you go "info lex" you get information on how to set up lex/yacc to do
> this.
>

I set the yyout to a FILE* and fix the scanner to fprintf(yyout....).

Now the collector can write back to same file.

Please tell me if this is the way.


Thanks


-- 
-----------------------------------------------------------
João Henrique Freitas - joaohf_at_gmail.com
Campinas-SP-Brasil
BSD051283
LPI 1
http://www.joaohfreitas.eti.br

[Cgreen-users] About collector tool, how to use.

[J. H. F. <jo...@gm...>]

Hello,

How I can use the collector tool?

Example:

In file tests/assertion_tests.c we can end the file with:

TestSuite *assertion_tests() {
    TestSuite *suite = create_test_suite();
    add_tests(suite, ); // this is right? maybe add_tests(suite,
assertion_tests, );??
    return suite;
}

Now we do:

src/collector tests/assertion_tests.c and we get this:

TestSuite *assertion_tests() {
    TestSuite *suite = create_test_suite();
    add_tests(suite, &integer_one_should_assert_true,
&integer_zero_should_assert_false, &one_should_assert_equal_to_one,
&zero_should_assert_not_equal_to_one,
&one_should_assert_long_equal_to_one,
&zero_should_assert_long_not_equal_to_one,
&one_should_assert_unsigned_long_equal_to_one,
&zero_should_assert_unsigned_long_not_equal_to_one,
&one_should_assert_long_long_equal_to_one,
&zero_should_assert_long_long_not_equal_to_one,
&one_should_assert_unsigned_long_long_equal_to_one,
&zero_should_assert_unsigned_long_long_not_equal_to_one,
&one_should_assert_short_equal_to_one,
&zero_should_assert_short_not_equal_to_one,
&one_should_assert_unsigned_short_equal_to_one,
&zero_should_assert_unsigned_short_not_equal_to_one,
&one_should_assert_char_equal_to_one,
&zero_should_assert_char_not_equal_to_one,
&one_should_assert_unsigned_char_equal_to_one,
&zero_should_assert_unsigned_char_not_equal_to_one,
&one_should_assert_float_equal_to_one,
&zero_should_assert_float_not_equal_to_one,
&one_should_assert_double_equal_to_one,
&zero_should_assert_double_not_equal_to_one,
&one_should_assert_long_double_equal_to_one,
&zero_should_assert_long_double_not_equal_to_one,
&double_differences_do_not_matter_past_significant_figures,
&double_differences_matter_past_significant_figures,
&double_assertions_can_have_custom_messages,
&identical_string_copies_should_match,
&case_different_strings_should_not_match,
&null_string_should_only_match_another_null_string,
&null_string_should_only_match_another_null_string_even_with_messages);
    return suite;

Ok!, Currently the collector tool don't write the results in file
tests/assertion_tests.c. But we can simulate this:

src/collector tests/assertion_tests.c > tests/tmp.c
cp tests/tmp.c tests/assertion_tests.c

Now, run the tests/all_tests and we get:

Running "main"...
Exception!: parameter_tests ->  -> Test "" failed to complete
Exception!: parameter_tests -> ▒�� -> Test "▒��" failed to complete
Exception!: parameter_tests -> 8_read_long_parameters_with_funky_names
-> Test "8_read_long_parameters_with_funky_names" failed to complete
Exception!: parameter_tests ->
�_read_two_parameters_with_varied_whitespace -> Test
"�_read_two_parameters_with_varied_whitespace" failed to complete
Exception!: parameter_tests ->
�_strip_box_double_to_leave_original_name -> Test
"�_strip_box_double_to_leave_original_name" failed to complete
Exception!: parameter_tests -> �_strip_d_macro_to_leave_original_name
-> Test "�_strip_d_macro_to_leave_original_name" failed to complete
Completed "main": 164 passes, 0 failures, 6 exceptions.


Something are wrong...

In TODO lists:

Collector
---------
Should write back to the same file when given a single file parameter,
stdout otherwise. <---------- I can do it.
Fix memory bug in slurp.c file. <----------- this works now.

Thanks

-- 
-----------------------------------------------------------
João Henrique Freitas - joaohf_at_gmail.com
Campinas-SP-Brasil
BSD051283
LPI 1
http://www.joaohfreitas.eti.br

Re: [Cgreen-users] Hilarious - Google have done a raid!

[J. H. F. <jo...@gm...>]

About memory checking:

This tool is very cool: http://www.fourmilab.ch/smartall/ and with
some ideas from Cmockery, Cgreen can do memory checking.

Can it be interesting to Cgreen project?

>>
>> The memory checking seems like a nice idea...
>
> I agree.
>
>>
>> /Thomas
>>
>>> yours, Marcus
>>> --
>>> Marcus Baker
>>> ma...@la...
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Cgreen-users mailing list
>>> Cgr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/cgreen-users
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Cgreen-users mailing list
>> Cgr...@li...
>> https://lists.sourceforge.net/lists/listinfo/cgreen-users
>>
>
>
>
> --
> -----------------------------------------------------------
> João Henrique Freitas - joaohf_at_gmail.com
> Campinas-SP-Brasil
> BSD051283
> LPI 1
> http://www.joaohfreitas.eti.br
>



-- 
-----------------------------------------------------------
João Henrique Freitas - joaohf_at_gmail.com
Campinas-SP-Brasil
BSD051283
LPI 1
http://www.joaohfreitas.eti.br

Re: [Cgreen-users] Hilarious - Google have done a raid!

[J. H. F. <jo...@gm...>]

Very funny.... :(
The scope is different.

>>
>> Looks like they have mashed together bits of other frameworks,
>> including
>> a slightly older version of Cgreen's mocks. Would have been nice to
>> have
>> had a credit somewhere :(. I wonder what we can steal back?
>>
>
> The memory checking seems like a nice idea...

I agree.

>
> /Thomas
>
>> yours, Marcus
>> --
>> Marcus Baker
>> ma...@la...
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Cgreen-users mailing list
>> Cgr...@li...
>> https://lists.sourceforge.net/lists/listinfo/cgreen-users
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Cgreen-users mailing list
> Cgr...@li...
> https://lists.sourceforge.net/lists/listinfo/cgreen-users
>



-- 
-----------------------------------------------------------
João Henrique Freitas - joaohf_at_gmail.com
Campinas-SP-Brasil
BSD051283
LPI 1
http://www.joaohfreitas.eti.br

Re: [Cgreen-users] Hilarious - Google have done a raid!

[Thomas N. <th...@ju...>]

30 dec 2008 kl. 19.52 skrev Marcus Baker:

> Hi...
>
> Check this out:
> http://www.google.com/gwt/n?u=http%3A%2F%2Fcmockery.googlecode.com%2Fsvn%2Ftrunk%2Fdoc%2Findex.html
>
> Looks like they have mashed together bits of other frameworks,  
> including
> a slightly older version of Cgreen's mocks. Would have been nice to  
> have
> had a credit somewhere :(. I wonder what we can steal back?
>

The memory checking seems like a nice idea...

/Thomas

> yours, Marcus
> -- 
> Marcus Baker
> ma...@la...
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Cgreen-users mailing list
> Cgr...@li...
> https://lists.sourceforge.net/lists/listinfo/cgreen-users

[Cgreen-users] Hilarious - Google have done a raid!

[Marcus B. <ma...@la...>]

Hi...

Check this out:
http://www.google.com/gwt/n?u=http%3A%2F%2Fcmockery.googlecode.com%2Fsvn%2Ftrunk%2Fdoc%2Findex.html

Looks like they have mashed together bits of other frameworks, including
a slightly older version of Cgreen's mocks. Would have been nice to have
had a credit somewhere :(. I wonder what we can steal back?

yours, Marcus
-- 
Marcus Baker
ma...@la...

Re: [Cgreen-users] test a static function.

[Marcus B. <ma...@la...>]

Hi...

João Henrique Freitas wrote:
> How I can test a static funcion with cgreen?

With C semantics the static function cannot be see outside the file.
Either you place your tests inside your source code file (and
conditionally compile them) or you macro out the static part.

#ifdef TESTING
    #define static_ extern
#else
    #define static_ static
#undef

That's all I can think of. Sounds like a good FAQ item.

yours, Marcus
-- 
Marcus Baker
ma...@la...

[Cgreen-users] test a static function.

[J. H. F. <jo...@gm...>]

Hello,

How I can test a static funcion with cgreen?


-------- calc.c -----------
#include "calc.h"

static int add_one(int a) {

   return a + 1;

}

static int add_two(int a) {

   return a + 2;

}

int add_one_and_two(int a) {

   printf("Adding: %d\n", add_one(a));

   printf("Adding: %d\n", add_two(a));

}


--------- calc.h ----------
#include <stdio.h>

static int add_one(int a);
static int add_two(int a);
int add_one_and_two(int a);

--------- test_calc.c -------------
#include <cgreen.h>
#include "calc.h"

void test_add_one() {
	
	assert_equal(2, add_one(1));
	
}

TestSuite *calc_test() {
   TestSuite *suite = create_test_suite();
   add_test( suite, test_add_one);
   return suite;
}

----------- all_test.c --------------
#include <cgreen.h>

TestSuite *calc_test();

int main(int argc, char **argv) {
   TestSuite *suite = create_test_suite();
   add_suite(suite, calc_test());
if (argc > 1) {
   return run_single_test(suite, argv[1], create_text_reporter());
}
   return run_test_suite(suite, create_text_reporter());
}

--------------
Compiling:

gcc -c all_test.c
gcc -c calc_test.c
gcc -c calc.c
gcc all_test.o calc.o test_calc.o -lcgreen -o all_test



Thanks
-- 
-----------------------------------------------------------
João Henrique Freitas - joaohf_at_gmail.com
Campinas-SP-Brasil
BSD051283
LPI 1
http://www.joaohfreitas.eti.br

[Cgreen-users] Cgreen build problems

[Marcus B. <ma...@la...>]

Hi Joao...

I'm having problems building CGreen on one of my home boxes.

It's an old one, a Linux box, and manages the sequence autogen.sh,
configure, make, make install. It doesn't manage "make check" though...

make[2]: Entering directory `/home/marcus/projects/sourceforge/cgreen/tests'
/bin/sh ../libtool --mode=link gcc  -L../src/.libs -g   -o all_tests
all_tests.o breadcrumb_tests.o messaging_tests.o assertion_tests.o
vector_tests.o constraint_tests.o parameters_test.o mocks_tests.o
slurp_test.o collector_tests.o -lm -lcgreen
gcc -g -o .libs/all_tests all_tests.o breadcrumb_tests.o
messaging_tests.o assertion_tests.o vector_tests.o constraint_tests.o
parameters_test.o mocks_tests.o slurp_test.o collector_tests.o
-L/home/marcus/projects/sourceforge/cgreen/src/.libs
/home/marcus/projects/sourceforge/cgreen/src/.libs/.libs/libcgreen.so
-ldl -lm -Wl,--rpath -Wl,/usr/local/lib
gcc:
/home/marcus/projects/sourceforge/cgreen/src/.libs/.libs/libcgreen.so:
No such file or directory
make[2]: *** [all_tests] Error 1

Any ideas? The double .lib is odd. Automake is version 1.4 though, and
gcc is 3.0.1 vintage.

I can develop on my old iBook G4, so this is not a major flaw right now.
However I cannot build the HTML with docbook, because...

xsl:import : unable to load tools/xsl/html/docbook.xsl

...even though the doc/README file says it should be there. Is the
README incorrect and I have to download these myself?

yours, Marcus
-- 
Marcus Baker
ma...@la...