On Sat, Jan 1, 2011 at 5:13 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:

> On Sat, 1 Jan 2011, Amr Shahin wrote:
>
> Hello folks,
>>
>> i'm attaching a sample very small unit tests using both check unit testing
>> library and the current curl testing framework integrated with curl, i was
>> hoping we could asses both and see which is more suitable to write unit
>> tests.
>>
>
> Hi and thanks a lot for your work on this!
>
>
> the code uses check is in the file llist_test.c. It's a classic unit
>> testing code, with all basic functions there setup, teardown and macros for
>> defining your tests, the output is well organized, you can see sample output
>> for both all success, and one failed test in the attached files. The only
>> downside for using check is that we're adding an extra dependency to curl,
>> my suggesstion is to add the .so version and check.h to the code base.
>>
>
> I have some objections and I will suggest another approach:
>
> check doesn't seem to be written to grok C89 compilers, have you checked
> (no pun intended) if it does?
>

   i contacted check-devel. will let you know when i get a reply. I wonder
however if this is important, the unit tests will be used by contributors
not client-developers, i guess all of contributors will be using a modern OS
and compiler.

>
> I would *REALLY* like to have the full test code bundled with curl and not
> depend on a separate download/package to get a decent test suite, and I find
>
>> 500K for a unittest for C quite much. Did anyone of you see how much we
>> would
>>
> need to copy to get a working check bundled?
>
>
    do we really need to attach the whole source of check? the size of the
.so is 32 KBs and the size of check.h is 16 KB.

>
> the other option is to use the testing setup already in libtest directory,
>> it's pretty easy to add more tests, but it's not as well-organized as using
>> check, all the tests use a function "int test(char *URL)" which may not be
>> suitable for unit tests.
>>
>> personally, i'm into using check. I'd love to hear what you guys think?
>>
>
> If you think the macros and verification methods check offers are good and
> nice to use, then I think we can simply implement them ourselves.
> fail_unless() and more.
>

   it's not only about macros. to have a full unit testing framework we'll
need to implement test suit handlers, test case handlers, output formatter
etc ...
   this sounds pretty much like re-writing check. And quoting from Vincent's
reply below, the quality won't be guaranteed (check is being used and it has
a dedicated team to support). The effor made to expand our current test can
be used to actually write the tests, few KBs sound like a small price :)

>
> The function named test() is just what we have so far with our test suite,
> there's no reason we couldn't change this if we want and need to. Personally
> I don't see why that is a problem. We can just have one C file for each
> family of tests that we do, and we can use fail_unless() style macros within
> them and we can have failures output look like other failures in our test
> suite.
>
> Using my approach, the same llist unittest series could be written like the
> attached file - consider it an example, we can of course tweak the details
> as we think and move ahead. Isn't that good enough? It then also works with
> our current infrastructure perfectly, with things such as valgrind, gdb and
> our own memory leak tool and more.
>
> The code looks good and it's a reasonable alternative, my vote still goes
for check, but i'm not married to this opinion, if we decide that using the
current test code i'll go for it.

*Amr*

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-01-02