The NorduGrid middleware comes with a fairly complete test-suite
that tests different functionalities of the middleware. The test-suite
consists of one program, called ngtest, that contains a variety of
xrsl-test-examples which can be submitted. The program can be used either
for testing a newly installed cluster or by a new user that wants to try out
a few simple things on NorduGrid for the first time. The program
comes with the nordugrid-client and the nordugrid-standalone-distribution.
To run the test-examples, run ngtest with test-numbers (see below) given
as arguments --- and maybe with the test-cluster specified with
the -c option. For example the command:

ngtest 0 2 9 35 78 -c grid.nbi.dk

will submit the test-jobs 0, 2, 9, 35 and 78 against the cluster
grid.nbi.dk.

All the test-jobs should finish without errors, so if one of them fails
there is a mistake either in the middleware or in the
cluster-setup. Please report middleware problems to the nordugrid-discuss
mailinglist

In the following the different test-examples will be shortly described. All
the referenced files can be found at the following location:

ftp://ftp.nordugrid.org/applications/test/

Testcases:

0: A complete job that tests a number of different things on a cluster
including downloading of inputfiles from different places. This job
downloads the source-code for a prime-number finding program, compiles it
and runs it for exactly two minutes. All prime-numbers that are found are
written to a file that can be downloaded, using ngget, by the user.

This test-job is the default one if the user does not specify any numbers.

1: A very basic hello, grid job. This test basically does nothing than
running the echo-program with the argument, Hello, Grid. This is the most
basic test, one can imagine. To see the output-file after the job
has finished, run ngget on the corresponding jobid and look in the file
stdout.

2: In this test, the User-Interface uploads an executable called echo.sh and
runs it with the argument, Hello, Grid. This is a simple test of whether
the User-Interface can upload an executable.
To submit this job, it is required that one has the file echo.sh in the
session-directory. This file is available from the ftp-location specified
above.

3: This test tests that one can specify the executable through a variable
set by a runTimeEnvironment. A runTimeEnvironment consists of a set of
environment variables that are set when
the user specifies that runTimeEnvironment on the cluster. Typically the
environment variables points to an installation of some software package
on the cluster. The test requires that the runtime-environment ECHOENV
is already installed on the cluster. An example of this
runtime-environment can be found in the ftp-directory given above.
This runTimeEnvironment should be installed on the cluster that one
wants to test.

4: This test tests the xrsl-attribute arguments. This attribute contains
the list of the arguments passed to the executable during execution. In this
case 3 arguments are passed to the executable. Again one can download the
output using ngget and view the result in the file stdout. One should see
exactly three numbers.

5: As test number 4, but here 10 arguments are passed to the executable.

6: This test tests that the arguments xrsl-attribute works in combination
with a variable that is defined through a runTimeEnvironment. This test
assumes that the runTimeEnvironment
ECHOENV has already been installed on the cluster.

7: As test number 6 but with 2 runtime-environments instead. This test
requires that the runtime-environments ECHOENV and MD5SUMENV have
already been installed on the cluster.

8: This test tests the xrsl-attribute executables, that specfies that
extra inputfiles should get executable-permission before the job is run.
To see that the test has run correctly, download the output using
ngget and look in the stdout-file.

Download-tests:

These tests test that the grid-manager correctly downloads all
input-files to the correct location. These
tests should all finish without errors. If not there is a problem. One
can get a feeling for the problem by looking in the stdout-file.

9 : In this test, the grid-manager downloads 1 input-file from the
NorduGrid http-server before running. This tests whether the grid-manager
-- the software that controls the job-submission on the clusters --
on the test-cluster is actually able to download from a http-server. 
10: The same as test number 9 but with 2 input-files.
11: The same as test number 9 but with 9 input-files. In this case,
these files consist of 3 files repeated 3 times. The first file
is a minute file, 19 bytes, the second file is a medium file, about 1
megabyte and the last file is a huge one, about 400 mega-bytes.
12: In this test, the grid-manager downloads 1 input-file from a
gridftp-server. A gridftp-server is basically a file-server containing
files but with access only through grid.
This tests whether the grid-manager on the cluster is
able to download from such a gridftp-server.
13: As test number 12 but with 2 input-files.
14: As test number 12 but with 9 input-files. These files are exactly
the same as in test 11 but the files are placed in a different place.
15: In this test, the grid-manager downloads 1 input-file from an
ordinary ftp-server. This tests whether the grid-manager on the cluster
is able to download from an ordinary ftp-server.
16: As test number 15 but with 2 input-files.
17: As test number 15 but with 9 input-files. The files are exactly the
same as in test 11 and 14.
18: In this test, the grid-manager contacts a so-called replica-catalog with
some logical filenames. A replica-catalog is a simple database which can
translate logical filenames to actual physical files residing somewhere
on a gridftp-server. After this translation, the grid-manager proceeds
to download the translated files.
19: As test number 18 but with 2 input-files.
20: As test number 18 but with 9 input-files. The files are exactly the
same as in test 11, 14 and 17.
21: A combination of tests 10, 13, 16 and 19. The grid-manager downloads two
files from an http-server, two files from a gridftp-server, two files
from an ordinary ftp-server and two files via the replica-catalog.

22-34: As the 9 tests above but in these we explicitly tell the grid-manager
not to download the input-files into the cache on the cluster but
directly into the session-directory of the job. The cache is a directory
on the remote cluster where files are placed and can be used by several
jobs.
35-47: As the 9 tests above but in these we tell the grid-manager to
use 10 ftp-threads when downloading the input-files. This case is very
similar to the tests above, but the download should in principle 
go a bit faster 
48-60: As the 9 tests above but here we tell the grid-manager to use
10 ftp-threads when downloading and download the files into the
session-directory not the cache.

Upload tests:

61: In this test, the User-Interface is requested to upload 1 input-files
directly. This tests whether the User-Interface is capable of doing so.
The test requires that the file echo.sh is available locally.
62: As test number 61 but with 2 input-files. This test requires that the files
echo.sh and somefile are available locally. somefile is a file of size of about
1 mega-byte.
63: As test number 61 but with 9 input-files. This test requires that the
files echo.sh, somefile and somehugefile are available locally. somehugefile
is a file of size of about 400 mega-bytes.

64-66: As the 3 tests above but the uploader-program is told to use
10 ftp-threads when uploading to the session directory.

67: This test is a combination of test number 21 and test number 62.
In total 8 files are downloaded to the remote cluster and 2 files
are uploaded by the User-Interface. In this test, the 2 files mentioned
previously echo.sh and somefile are needed locally for the upload.
68: As test number 67 but with 10 ftp-threads both in uploading
and downloading.

Various tests of attributes:

69: In this test, the xrsl cluster-attribute is tested. This test-job
should in all cases go the cluster lscf.nbi.dk.
70: This test tests whether one can specify several versions in
the xrsl cluster-attribute using the or-operator |. This test-job
should go either to the cluster grid.tsl.uu.se or the cluster
grid.quark.lu.se.
71: This test tests whether the xrsl cluster-attribute works in combination
with not-equal operator !=. This test-job should under no circumstances
go to the cluster lscf.nbi.dk
72: This test tests whether the cluster- and queue attributes works
together. This test-job should go to the cluster grid.nbi.dk into
the short-queue. You can check that this is correct by looking
at the NorduGrid Grid Monitor while the job is running.

73: This test submits a job requiring the same version of the NorduGrid 
middleware on the
remote cluster as the version that is used to submit the job. You can check
that this is correct by checking your version (with ngsub -v) with the
version of the remote cluster. Here you can use the NorduGrid Grid
Monitor to find the version of that cluster.This test specifies that the test-job should only go to a cluster with the same version of the NorduGrid middleware as that of the client. This tests
whether the xrsl-attribute middleware works as claimed.
74: As test number 73 but the job can go to a cluster with the middleware
version bigger or equal to that of the client. 
75: As test number 73 but the job can go to a cluster with the middleware
version less or equal to that of the client.

76: This test tests that one can get extra environment-variables set
when the job is running by using the xrsl attribute environment. If the
job finishes without errors, this works as intented.
77: This test tests that rsl-substitution works for the executable-attribute.
78: This test tests that rsl-substitution works for the arguments-attribute
79: This test tests that brokering works when the user specifies the
xrsl-attribute CPUTime as for example 2 hours. 

80: This test tries to upload 1 output-file to a gridftp-server. The output of the job specifies the location of the output-files. If the job finishes
successfully, the user should erase the file again using the command
given in the output of the job. You can get the output by using ngget
and looking in the file stdout.
81: As test number 80 but with 2 output-files.
82: As test number 80 but with 9 output-files. The files used comes
from different ftp- and gridftp-servers connected to NorduGrid.
83: As test number 80 but here the test uploads to a physical location
specified by the replica-catalog. The grid-manager contacts the
replica-catalog which resolves the logical address to a physical one.
After that the grid-manager uploads the file to that location. The user
should again remember to erase the corresponding output-files.
84: As test number 83 but with 2 output-files.
85: As test number 85 but with 9 output-files.