Re: is there a way to debug only one of the test cases in a test program

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