octave-maintainers
[Top][All Lists]
Advanced

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

Re: tests with temporary files


From: Rik
Subject: Re: tests with temporary files
Date: Fri, 12 Jul 2013 11:42:11 -0700

On 07/12/2013 10:00 AM, address@hidden wrote:
> Message: 5
> Date: Fri, 12 Jul 2013 17:56:49 +0100
> From: Carn? Draug <address@hidden>
> To: address@hidden
> Subject: writing tests in Octave: IO functions, shared test block and
>       test    error with testif HAVE_X
> Message-ID:
>       <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi
>
> I'm at the moment in need to write tests for the image IO functions
> (imread, imwrite and imfinfo) and have some questions:
>
> 1) When testing the writing of files where should they be written to?
> Does tmpnam () works in windows as well?

tmpnam() is a good choice.  It writes into the directory P_tmpdir which in
turn respects user's environment variables such as TMPDIR.

>
> 2) And how can the file be removed after? imread() has a test that
> writes a file, reads it back, removes the file, and only then runs the
> test so the file is removed if the test fails. However, if imread
> gives an error the file is never removed. I have wrapped the test in
> an unwind_protect block to make sure the file is always removed.
> Still, should we make this simpler somehow?

unwind_protect_cleanup is a pretty standard way of doing this.  You could
also take a look at mkstemp().  The second option to the function is a flag
to delete the temporary file when Octave exits.  The syntax isn't quite the
same as tmpnam so you would have to write:

[fid, fname] = mkstemp ([P_tmpdir() filesep() "oct-imgtxst-XXXXXX", true);
close (fid);

This might still be useful if you can afford to re-use the same temporary
file name across multiple test blocks.  Another slight difference is that
the file would not be deleted until Octave exited rather than immediately
after the test failed.  Still, I wouldn't think that would be a problem. 

>
> 3) For testing reading files, where can test files be placed? Would be
> nice to have a solution that could also be reused by packages (such
> files are a nice place for easter eggs). At the moment we only have
> default.img but that's not enough for all the tests that I would like
> to have.
Thats a good question.  'default.img' is meant to be seen by users so it
needs to go in to the IMAGE_PATH.  These test files should, presumably, not
be seen by anyone.  It might make sense to put them in a 'private/'
directory so that they are not visible.  I would worry, however, if we have
a lot of image files mixed up with .m files in the scripts/image/private
directory.  What about making a directory under test/ that could hold all
the files and placing a .tst script there?  This seems a good way of
removing it from the scripts directory which is generally installed as-is
by 'make install'.  See test/nest for an example.
>
> 4) We have the testif #HAVE_XX to run the tests only if octave was
> built with that library. How can that be used when testing for error?

%!error is just syntatic sugar to make it easy to write tests, but you can
certainly go the long way around depending on how many tests you have to
write.  Look at test.m and the section on errors starting at line 386.  The
basic syntax would be

%!testif HAVE_XXX
%!  try
%!    some error producing code
%!  catch
%!    # got error, check that it is the correct one
%!   catch_block_used = true;
%!  end_try_catch
%!  if (! catch_block_used)
%!   error ("code to produce error, didn't produce an error");
%!  endif

You could also just use eval() and check the error status for simpler tests.

--Rik


reply via email to

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