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

[Irene Huang]

hi, all

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?

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.

Thanks in advance
--Irene


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

[Daniel Gollub]

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

[Irene Huang]

Daniel,

Thanks for the help :). Your patch is much more easier then what I am
doing :).
In fact I am also using CK_FORK="no" as well, since it isn't easy to
debug multi-processes using dbx either (not that I am aware of). :)

--Irene
Daniel Gollub wrote:

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

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