[Top][All Lists]

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

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

From: Paul Kienzle
Subject: Re: Converting DejaGNU tests to Paul's test/assert infrastructure
Date: Mon, 24 Oct 2005 18:33:42 -0400

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.


        %!shared fn
        %!function [a,b,c] = fn(e,f,g)
        %! [a,b,c] = deal(e,f,g);
        %! [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);
    fn = @__test_f123;
    function fn = __test__(fn)
      [a,b,c] = fn(1,2,3);
    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

reply via email to

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