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 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?

> 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.

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.

-- 
  / daniel.haxx.se

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html