On Sun, Jan 2, 2011 at 3:13 AM, Amr Shahin <amrnablus_at_gmail.com> wrote:

>
>
> 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*
>
>
i got this reply from check-devel:
I don't recall any hard dependencies on C99; I suggest giving it a
shot and see what happens. Are we still on deciding ? If so i can try
compiling with a C98

*Amr*

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