On Sun, Jan 2, 2011 at 3:13 AM, Amr Shahin <[email protected]> wrote:
> > > On Sat, Jan 1, 2011 at 5:13 PM, Daniel Stenberg <[email protected]> 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
