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