How to test?

[Aiosa]

It is very hard to find some info about testing. I would appreciate adding some basic HOWTO, the only thing I found is

3. Optionally, type `make check' to run any self-tests that come with the package.

hidden somewhere in the unformatted INSTALL file which looks very up-to-date with its copyright year up to 2008. Instead of trying to build the binary with make and finding out which parameters/variables I forgot to add to the preprocessor, compiler or the final program, I would like to have a simple-to-follow scenario.

Cool project. Thank you!

[ruven]

The INSTALL file is in fact just a standard GNU automake boilerplate install file. You're right, it's not up to date, so I just pushed a commit which adds the latest version. Though that doesn't radically change the contents of that file.

In terms of ./configure parameters, you can get a full list through the standard command

./configure --help

In terms of testing, there aren't any unit tests or anything like that if that's what you are looking for. Probably the most useful way to test is just by logging - just set the VERBOSITY run-time environment variable to get detailed logging while iipsrv runs.

There is a DEBUG pre-processor directive you can define at compile-time, but it just by-passes the FCGI loops, so it's not so useful in most cases. For more detailed logging wiithin KakacuImage.cc or OpenJPEG.cc, you can define DEBUG at the top of these files to get extra debug-level logging just in those classes.

Some more sophisticated ways of testing would certainly be a good thing as would be a HOWTO. What kind of testing are you looking to carry out exactly?

[Aiosa]

I was hoping I can get my hands on some test template that would use prepared data to run on a protocol in a loop.

Mostly, the behavioural is similar: fetch image meta (existing / nonexisting) + fetch image data (+various params, repeated). Then I could feed this to Valgrind, for example :) Yes, I can run Apache+FCGI. Yes, I can compile the source to a native executable and run with memcheck. Doing both (manual testing+memcheck) now seems a bit hard to do. Though I am not very familiar with FCGI capabilities and I can miss something.

[ruven]

The way I usually use Valgrind is to have Apache, Lighttpd or NginX or whatever run normally, but have them configured to just point to an FCGI process rather than have them start iipsrv themselves. There are instructions on how to do this here: https://iipimage.sourceforge.io/documentation/server#forwarding. You can then start iipsrv yourself on the command line manually: https://iipimage.sourceforge.io/documentation/server#commandline

This way you can use Valgrind as you would any other binary:

valgrind src/iipsrv.fcgi --bind 0.0.0.0:9000

To make a series of requests with different images or parameters, the simplest way is to put them in a list and use curl or similar to send the request sequence to the web server and watch the output from Valgrind.

It would be useful, as you say, to have another way of doing this without having to use a web server and FCGI. I'll look into how iipsrv could do this.

[Aiosa]

Thank you, the command-line setup should be sufficient.

[ruven]

Having more control over testing is definitely useful, so I've just pushed a commit which you might find useful (https://github.com/ruven/iipsrv/commit/37aebe62c36c504524cc91e8a26193fbcb94a9c6). It allows you to test iipsrv without the need for FCGI or a web server. If you compile with DEBUG defined at the configure stage:

CXXFLAGS="-DDEBUG" ./configure
make

The resulting binary can be run on the command line and will accept through standard input requests written in any supported image API with the output sent to the file iipsrv.debug. This also works with pipes or redirects to test a list of requests:

% iipsrv.fcgi < request_list.txt

I've also added a new section on debugging to the README.