-
Notifications
You must be signed in to change notification settings - Fork 19
Testing
Unit tests for the cf4ocl functions and macros are implemented using the GLib testing framework.
After building cf4ocl from source a number of test executables
are placed in the tests/lib folder within the build directory. These
executables can be invoked directly one by one, or can be invoked simultaneously
using the gtester tool, e.g.:
$ gtester -k ./tests/lib/test_*
The -k switch orders gtester to keep running tests even if a test fails. The
tests are exaustive and have uncovered a number of bugs in several
OpenCL implementations.
Since many OpenCL implementations report a large number of memory leaks, it
can become difficult to detect leaks in cf4ocl. For this purpose, most tests
can be executed against the provided OpenCL stub. This stub provides one
platform with four devices, and implements most of the functionality of a real
OpenCL implementation, with the notable exception of actually compiling and
executing kernels. Most importantly, the stub allocates and deallocates memory
as expected, for example when creating and destroying a context with the
clCreateContext() and clReleaseContext()
functions, respectively. The TESTS_USE_OPENCL_STUB option in the CMake build
configuration defines whether the tests are compiled against the stub or against
the configured OpenCL ICD/implementation.
The default device to be used in most tests is defined with the
TESTS_DEVICE_INDEX build option. This definition can be overridden with the
CCL_TEST_DEVICE_INDEX environment variable. For example, the following command
runs the tests against device #2:
$ CCL_TEST_DEVICE_INDEX=2 gtester -k ./tests/lib/test_*
The index of all devices present in the system can be determined with the
ccl_devinfo utility:
./src/utils/ccl_devinfo -o
Tests for the command-line utilities, ccl_c and ccl_devinfo, as well as tests for the provided examples, are implemented with the bats testing framework.
After building cf4ocl from source the test scripts for the
cf4ocl examples and utilities are placed within the build directory in the
tests/examples and tests/utils folders, respectively. The tests are invoked
with the bats command:
$ bats ./tests/examples ./tests/utils
The main device used for the examples and utilities tests is specified in the same manner as in the unit tests, i.e., either in the build configuration and/or as an environment variable. For example, the following command runs the utilities tests against device #2:
$ CCL_TEST_DEVICE_INDEX=2 bats ./tests/utils
On Windows, within the MSYS2 shell, the bats command may have to be invoked
as /usr/local/libexec/bats.
After building cf4ocl from source, the test_all.sh is
placed in the tests folder within the build directory. This script runs the
library, examples and utilities tests for all OpenCL devices available in the
system.
Since cf4ocl heavily relies on glib, the associated debugging
techniques can also be used for debugging cf4ocl applications.
For example, setting the log domain to cf4ocl2 will cause cf4ocl functions
to print debug messages. These messages allow, in case of errors, to obtain the
full stack trace of the error. The following command executes the canon
example with cf4ocl log messages turned on:
G_MESSAGES_DEBUG=cf4ocl2 ./src/examples/canon
Log messages are more detailed if cf4ocl is built in "Debug" mode, an option
which can be specified in the CMake build configuration. In this mode, another
debugging option, DEBUG_OBJ_LIFETIME, is made available in the build
configuration. If this option is set to ON, the referencing and dereferencing
of all cf4ocl wrapper objects is logged in the debug stream, which is useful
for tracking possible memory leaks.
The library tests have a specific log domain, ccl-tests, which can be set
alternatively or in combination with the cf4ocl2 domain. For example:
$ G_MESSAGES_DEBUG=cf4ocl2,ccl-tests gtester -k ./tests/lib/test_*