Re: Converting DejaGNU tests to Paul's test/assert infrastructure

[Paul Kienzle]

On Oct 24, 2005, at 9:20 AM, David Bateman wrote:
> However, nested functions are not permitted with Paul's test 
> infrastructure. I haven't looked at test.m yet to see, but how 
> complicated would it be to include nested functions in test.m?

Nested functions defined on the command line is useful in another 
context.  The first thing my application does when it starts up a new 
octave interpreter is send some function definitions from the remote 
machine.  These are stored in m-files which use private functions on 
the client, but when evaluated on the server these functions all become 
public.

For the purposes of test we may want to define helper functions in a 
separate function block.  This name would be shared amongst the various 
tests and forgotten once all the tests are complete, or when a new 
share block is declared.  Because it would be in its own eval, it 
wouldn't require nested functions to support.

To avoid name collisions, the function will have to defined as 
__test_f### where ### is a unique number.  This can be assigned to the 
shared name. We will have to clear __test_f### by hand at the end of 
the shared context.

E.g.,

        %!shared fn
        %!function [a,b,c] = fn(e,f,g)
        %! [a,b,c] = deal(e,f,g);
        %!test
        %! [a,b,c] = fn(1,2,3);
        %! assert(a,1);
        %! assert(b,2);
        %! assert(c,3);

would expand to:

    function [a,b,c] = __test_f123(e,f,g)
      [a,b,c] = deal(e,f,g);
    endfunction
    fn = @__test_f123;
    function fn = __test__(fn)
      [a,b,c] = fn(1,2,3);
      assert(a,1);
      assert(b,2);
      assert(c,3);
    endfunction
    __test__(fn);
    clear __test_f123;

> Another issue I have is that although "%!error" exists there is no 
> equivalent "%!warning" for the warning conditions. Again how 
> complicated would it be to add this?

AFAIK there is no way to capture warnings.

One approach would be to capture stderr to a string then read that 
string.  Internally, error.cc writes directly to std::cerr, so we would 
have to write an oct-file to redirect it to a string, and to capture 
and clear the string at appropriate times.

This same technique should work to capture usage statements.

Note for more sophisticated string comparisons we should be using 
regular expressions.  The current octave-forge regexp function does not 
use a compatible interface and will eventually be changed.

        - Paul