On Friday 18 April 2008 18:44:51 Irene Huang wrote:
> does any one know whether there's any easy way to debug only one of the
> case among the several cases in a test program? Like using an special
> ctest commandline option, to prevent us from commenting out anything in
> the code and remake it?
There is one thing you should know about our testsuite. It's a mix of ctest
(from CMake) and check, an unit testframework -
http://check.sourceforge.netctest and check are independent of each other. The tests make use of the check
framework, which makes it really easy to write tests and control testruns.
Once everything is build you can find each unittest as binary in
$build/tests - you can call them directly without ctest.
But this will call all testcase of this unit - something you don't want when
debugging a single testcase.
ctest is actually only used for "make test" which will call those test
binaries one by one and summarize the result. And other stuff like running
tests with valgrind and/or collecting code coverage results form the tests -
last but not least commit them to a central dashboard:
http://opensync.org/testing (and having continuous testing - which is really
cool, since i can bothered everytime when i break something on Solaris ;))
> for example, ipc has more than 10 test cases and I am only interested in
> ipc_create. My way of doing it is to comment out all the other
> create_cases code and remake ipc. I might be using the silliest way.
Actually I miss this kind of feature as well. Right now I'm doing something
similar, instead of commenting them all out - I make use of the "Suite *s2"
variable which you might found in some tests already. But maybe we should
hack check itself and provide optional command parsing function. Parsing the
argument and only run testcases given by commandline... or something like
that.
Btw. there is a useful environment variable you should know when debugging
tests: CK_FORK=no - With this check will not fork the testcases - this is
quite helpful when running those within a debugger. Maybe dbx is more
powerful then gdb to handle forked processes... not quite sure. (Maybe, i'm
also lacking in gdb-skills ;))
best regards,
Daniel
Index: tests/ipc-tests/check_ipc.c
===================================================================
--- tests/ipc-tests/check_ipc.c (revision 3271)
+++ tests/ipc-tests/check_ipc.c (working copy)
@@ -2247,10 +2247,10 @@
Suite *ipc_suite(void)
{
Suite *s = suite_create("IPC");
-// Suite *s2 = suite_create("IPC");
+ Suite *s2 = suite_create("IPC");
create_case(s, "ipc_new", ipc_new);
- create_case(s, "ipc_create", ipc_create);
+ create_case(s2, "ipc_create", ipc_create);
create_case(s, "ipc_connect", ipc_connect);
create_case(s, "ipc_payload", ipc_payload);
create_case(s, "ipc_payload_wait", ipc_payload_wait);
@@ -2274,7 +2274,7 @@
create_case(s, "ipc_timeout", ipc_timeout);
- return s;
+ return s2;
}
int main(void)
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel