guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Recent addition to numbers.c


From: Dirk Herrmann
Subject: Re: Recent addition to numbers.c
Date: Fri, 7 Sep 2001 01:11:37 +0200 (MEST)

On Thu, 6 Sep 2001, Thien-Thi Nguyen wrote:

>    From: Michael Livshin <address@hidden>
>    Date: 04 Sep 2001 01:27:46 +0300
> 
>    very good of you to raise the question, really.  there's plenty to
>    test in Guile's C interface.
> 
> the mechanics of introducing "make check" testing for numbers.c in
> libguile are pretty simple.  below is a patch to Makefile.am, followed
> by a (hastily) extracted numbers.test.c.  at this time, "make check"
> with these changes fails.  when i run "gdb numbers.test", i see:
[... example extracted]

Thanks for providing the example.  However, what Michael and I am thinking
of is how to integrate the testing of the C interface with the current
scheme level testsuite.  Like, having a lot of C files with functions to
be tested, getting each of them compiled into a shared library object and
having the scheme testsuite link each of the ahred libs, execute the
corresponding functions, and report the successes and failures in the same
manner as the other test cases currently do.

For example, each C level test file has a function SCM test_init(void),
which gets called immediately after the dynamic object has been
linked.  The test functions are named uniformly test_case_0, test_case_1,
... and are defined as follows:

SCM test_case_0 (SCM do_test)
{
  if (SCM_FALSEP (do_test)) {
    return scm_str2string ("does function foo work?");
  } else {
    /* Code to check function foo.  Returns #t on success, #f on failure. 
     * Returning something else means the test case is unresolved.  You
     * can also throw something.  Refer to the test-lib for a detailed
     * description how test cases are implemented.  */
    ...
  }
}

The test suite would iterate over the functions test_case_0, test_case_1,
etc. and would first call each function with #f to get the description
string of the test case, and then call the function with #t to have the
actual test performed.  While the above is just a first shot into the
dark, a solution like this could certainly be made much more convenient
using some macros that build the function framework for each test case.

Best regards
Dirk




reply via email to

[Prev in Thread] Current Thread [Next in Thread]