viewcvs.cgi/test/README.txt


Radiance Testing Framework
--------------------------

A toolkit to test all (eventually) components of the Radiance
synthetic image generation system for conformance to their
specification.


Limitations

For the moment, we use PyUnit to run our tests. This means that
we're restricted to test only complete programs, and not actual
units (since PyUnit was designed to test Python units, not C).
A C-level testing framework may be added later.

There's no good way to automatically test GUI programs like
rview. We have to rely on good human testers to check whether
those work correctly or not.


Requirements

You need a working installation of Python 2.1 (or newer) on your
system. The reason for this is that the PyUnit framework isn't
included with earlier versions. If you prefer to use an older
Python (back to 1.5.2), you can get PyUnit here, and install it
somewhere on your PYTHONPATH:
  http://pyunit.sourceforge.net/

Our testing framework currently assumes that the Radiance files
reside in the following local file tree (seen from the "test/"
subdirectory where this file resides):

  executables:    ../bin/*[.exe]
  support files:  ../lib/*
  data files:     ./test data/*

This is the location where the experimental SCons build system
will place everything, so it might be easiest to compile Radiance
using SCons for testing.
The space character in the name of the test data directory is
deliberate, because it is a design requirement that all our
executables can handle path names with spaces.


How to run tests

On unix systems, just type "run_all.py" in this directory to
test everything. If that file doesn't have execute rights, you
can supply it to the python interpreter as its single argument:
"python run_all.py". You can also run individual test suites from
the "py_tests" directory directly: "python test_getinfo.py".

On Windows, this should usually work as well. As an alternative,
use the "winrun.bat" script. WARNING: You need to change the
paths in this script to match your Python installation first.


What gets tested

There are several test groups, each containing a number of test
suites, each containing one or more tests. When running tests,
the name of the test groups and test suites will get printed to
the console, the latter with an "ok" if they succeeded.

If any test fails, there will be diagnostic output about the
nature of the failure, but the remaining tests will continue to
be executed. Note that several utility programs may be used to
access the results of other calculations, so if eg. getinfo is
broken, that may cause a number of seemingly unrelated tests to
fail as well.


How to report failures

If any of the tests fail on your platform, please report your
results (and as much ancilliary information about your system and
Radiance version as possible) to the radiance code development
mailing list on http://www.radiance-online.org/
The developers will then either try to fix the bug, or instruct
you on how to refine your testing to get more information about
what went wrong.


How to contribute test cases

The list of tests run is still very much incomplete, but will
hopefully grow quickly. You can contribute by creating tests too!
Please ask on the code development mailing list first, so that we
can avoid overlaps between the work of different contributors.

There are two classes of tests to be considered:

- Testing individual executables
  This means that an individual program like ev, xfom, or getinfo
  is tested with typical input data, and the output is compared
  against the expected result.

- Testing specific calculations
  This will mainly affect the actual simulation programs rpict
  and rtrace. For example, there should be a test suite for every
  material (and modifier) type, which uses rtrace to shoot a
  series of rays against a surface under varying angles, in order
  to verify material behaviour under different parameters. Tests
  of this kind may require a custom script.

Contributed tests can be of two kinds. In the simplest case, you
can contribute a small(!) set of test data, the command line(s)
used to run your tests on them, and a list of expected results.
Result comparisons are typically done in text form (by line).
If the result is a picture, we'll use ttyimage to pick out a few
scan lines for comparison (the image dimensions must be less than
128 pixels). Other binary data needs to be converted into a
suitable text representation as well. If you're not sure what to
use, the developers can help you about that point. They will then
also wrap your test case into a Python module for integration
with the framework.

Contributors sufficiently familiar with the Python programming
language and the PyUnit test framework can also submit complete
test suites in Python. Please use the existing tests in the
"py_tests" directory as a template, and check out the helper
modules in "py_tests/unit_tools".

In any case, please note that we can't use any shell scripts or
similar tools in our tests. All tests should be able to run on
all supported platforms, where your favourite shell may not be
available. The Python programming language is available for
pretty much any platform, so we decided to use only that.


Revision:	1.2
Committed:	Sun Jul 4 12:05:33 2004 UTC (21 years, 4 months ago) by schorsch
Content type:	text/plain
Branch:	MAIN
CVS Tags:	rad3R7P2, rad3R7P1, rad3R6, rad3R6P1, rad3R8, rad3R9
Changes since 1.1:	+6 -6 lines
Log Message:	minor fixes.
#	User	Rev	Content
1	schorsch	1.1
2			Radiance Testing Framework
3			--------------------------
4
5			A toolkit to test all (eventually) components of the Radiance
6			synthetic image generation system for conformance to their
7			specification.
8
9
10			Limitations
11
12			For the moment, we use PyUnit to run our tests. This means that
13			we're restricted to test only complete programs, and not actual
14			units (since PyUnit was designed to test Python units, not C).
15			A C-level testing framework may be added later.
16
17	schorsch	1.2	There's no good way to automatically test GUI programs like
18			rview. We have to rely on good human testers to check whether
19			those work correctly or not.
20
21	schorsch	1.1
22			Requirements
23
24			You need a working installation of Python 2.1 (or newer) on your
25			system. The reason for this is that the PyUnit framework isn't
26			included with earlier versions. If you prefer to use an older
27			Python (back to 1.5.2), you can get PyUnit here, and install it
28			somewhere on your PYTHONPATH:
29			http://pyunit.sourceforge.net/
30
31			Our testing framework currently assumes that the Radiance files
32			reside in the following local file tree (seen from the "test/"
33			subdirectory where this file resides):
34
35			executables: ../bin/*[.exe]
36			support files: ../lib/*
37			data files: ./test data/*
38
39			This is the location where the experimental SCons build system
40			will place everything, so it might be easiest to compile Radiance
41			using SCons for testing.
42			The space character in the name of the test data directory is
43			deliberate, because it is a design requirement that all our
44			executables can handle path names with spaces.
45
46
47			How to run tests
48
49			On unix systems, just type "run_all.py" in this directory to
50			test everything. If that file doesn't have execute rights, you
51			can supply it to the python interpreter as its single argument:
52			"python run_all.py". You can also run individual test suites from
53			the "py_tests" directory directly: "python test_getinfo.py".
54
55			On Windows, this should usually work as well. As an alternative,
56			use the "winrun.bat" script. WARNING: You need to change the
57			paths in this script to match your Python installation first.
58
59
60			What gets tested
61
62			There are several test groups, each containing a number of test
63			suites, each containing one or more tests. When running tests,
64			the name of the test groups and test suites will get printed to
65			the console, the latter with an "ok" if they succeeded.
66
67			If any test fails, there will be diagnostic output about the
68			nature of the failure, but the remaining tests will continue to
69			be executed. Note that several utility programs may be used to
70			access the results of other calculations, so if eg. getinfo is
71			broken, that may cause a number of seemingly unrelated tests to
72			fail as well.
73
74
75			How to report failures
76
77			If any of the tests fail on your platform, please report your
78			results (and as much ancilliary information about your system and
79	schorsch	1.2	Radiance version as possible) to the radiance code development
80			mailing list on http://www.radiance-online.org/
81	schorsch	1.1	The developers will then either try to fix the bug, or instruct
82			you on how to refine your testing to get more information about
83			what went wrong.
84
85
86			How to contribute test cases
87
88			The list of tests run is still very much incomplete, but will
89			hopefully grow quickly. You can contribute by creating tests too!
90			Please ask on the code development mailing list first, so that we
91			can avoid overlaps between the work of different contributors.
92
93			There are two classes of tests to be considered:
94
95			- Testing individual executables
96			This means that an individual program like ev, xfom, or getinfo
97			is tested with typical input data, and the output is compared
98			against the expected result.
99
100			- Testing specific calculations
101			This will mainly affect the actual simulation programs rpict
102			and rtrace. For example, there should be a test suite for every
103			material (and modifier) type, which uses rtrace to shoot a
104			series of rays against a surface under varying angles, in order
105			to verify material behaviour under different parameters. Tests
106			of this kind may require a custom script.
107
108			Contributed tests can be of two kinds. In the simplest case, you
109			can contribute a small(!) set of test data, the command line(s)
110			used to run your tests on them, and a list of expected results.
111			Result comparisons are typically done in text form (by line).
112			If the result is a picture, we'll use ttyimage to pick out a few
113			scan lines for comparison (the image dimensions must be less than
114			128 pixels). Other binary data needs to be converted into a
115			suitable text representation as well. If you're not sure what to
116			use, the developers can help you about that point. They will then
117			also wrap your test case into a Python module for integration
118			with the framework.
119
120			Contributors sufficiently familiar with the Python programming
121			language and the PyUnit test framework can also submit complete
122			test suites in Python. Please use the existing tests in the
123			"py_tests" directory as a template, and check out the helper
124			modules in "py_tests/unit_tools".
125
126			In any case, please note that we can't use any shell scripts or
127			similar tools in our tests. All tests should be able to run on
128			all supported platforms, where your favourite shell may not be
129			available. The Python programming language is available for
130			pretty much any platform, so we decided to use only that.
131
132
133