118 lines
3.9 KiB
Plaintext
118 lines
3.9 KiB
Plaintext
The file format of the test suite is a very simple and extendable format. All
|
|
data for a single test case resides in a single ASCII file. Labels mark the
|
|
beginning and the end of all sections. Each label must be written in its own
|
|
line and is resembling XML/HTML.
|
|
|
|
Each file is split up in three main sections: reply, client and verify. The
|
|
reply section is used for the server to know what to send as a reply for the
|
|
requests curl sends, the client section defines how the client should behave
|
|
while the verify section defines how to verify that the data stored after a
|
|
command has been run ended up correctly.
|
|
|
|
Each main section has a number of available subsections that can be
|
|
specified, that will be checked/used if specified. This document includes all
|
|
the subsections currently supported.
|
|
|
|
<reply>
|
|
<data [nocheck=1]>
|
|
data to sent to the client on its request and later verified that it arrived
|
|
safely. Set the nocheck=1 to prevent the test script to verify the arrival
|
|
of this data.
|
|
</data>
|
|
<datacheck [nonewline=yes]>
|
|
if the data is sent but this is what should be checked afterwards. If
|
|
'nonewline' is set, we will cut off the trailing newline of this given data
|
|
before comparing with the one actually received by the client
|
|
</datacheck>
|
|
<size>
|
|
number to return on a ftp SIZE command (set to -1 to make this command fail)
|
|
</size>
|
|
<mdtm>
|
|
what to send back if the client sends a (FTP) MDTM command, set to -1 to
|
|
have it return that the file doesn't exist
|
|
</mdtm>
|
|
<cmd>
|
|
special purpose server-command to control its behavior *before* the
|
|
reply is sent
|
|
</cmd>
|
|
<postcmd>
|
|
special purpose server-command to control its behavior *after* the
|
|
reply is sent
|
|
</postcmd>
|
|
</reply>
|
|
|
|
<client>
|
|
|
|
<server>
|
|
protocols as in 'http' 'ftp' etc. Give only one per line. Used for test cases
|
|
500+ (at this point) to specify which servers the test case requires. In the
|
|
future all test cases should use this. Makes us independent of the test
|
|
case number.
|
|
</server>
|
|
|
|
<killserver>
|
|
Using the same syntax as in <server> but when mentioned here these servers
|
|
are explicitly KILLED when this test case is completed. Only use this if there
|
|
is no other alternatives. Using this of course requires subsequent tests to
|
|
restart servers.
|
|
</killserver>
|
|
|
|
<tool>
|
|
Name of tool to use instead of "curl". This tool must be built and exist
|
|
in the libtest/ directory.
|
|
</tool>
|
|
|
|
<name>
|
|
test case description
|
|
</name>
|
|
|
|
<command [option=no-output]>
|
|
command line to run, there's a bunch of %variables that get replaced
|
|
accordingly. more about them elsewhere
|
|
|
|
Set 'option=no-output' to prevent the test script to slap on the --output
|
|
argument that directs the output to a file. The --output is also not added if
|
|
the client/stdout section is used.
|
|
|
|
Available substitute variables include:
|
|
%HOSTIP - IP address of the host running this test
|
|
%HOSTPORT - Port number of the HTTP server
|
|
%HTTPSPORT - Port number of the HTTPS server
|
|
%FTPPORT - Port number of the FTP server
|
|
%FTPSPORT - Port number of the FTPS server
|
|
%SRCDIR - Full path to the source dir
|
|
%PWD - Current directory
|
|
</command>
|
|
|
|
<file name="log/filename">
|
|
this creates the named file with this content before the test case is run
|
|
which is useful if the test case needs a file to act on.
|
|
</file>
|
|
|
|
</client>
|
|
|
|
<verify>
|
|
<errorcode>
|
|
numerical error code curl is supposed to return
|
|
</errorcode>
|
|
<strip>
|
|
One regex per line that is removed from the protocol dumps before the
|
|
comparison is made. This is very useful to remove dependencies on dynamicly
|
|
changing protocol data such as port numbers or user-agent strings.
|
|
</strip>
|
|
<protocol [nonewline=yes]>
|
|
the protocol dump curl should transmit, if 'nonewline' is set, we will cut
|
|
off the trailing newline of this given data before comparing with the one
|
|
actually sent by the client
|
|
</protocol>
|
|
<stdout>
|
|
This verfies that this data was passed to stdout.
|
|
</stdout>
|
|
<file name="log/filename">
|
|
the file's contents must be identical to this
|
|
</file>
|
|
<upload>
|
|
the contents of the upload data curl should have sent
|
|
</upload>
|
|
</verify>
|