m (→Running the tests) |
(Document non-interactive use of testrunner.) |
||
| Line 3: | Line 3: | ||
== Akonadi Testrunner == | == Akonadi Testrunner == | ||
| − | Igor's GSoC project, found in kdepimlibs/akonadi/tests/testrunner. | + | Igor's GSoC project, found in kdepimlibs/akonadi/tests/testrunner. The Akonadi Testrunner sets up an isolated Akonadi server (which implies a separated D-Bus server) based on an environment configuration file. |
| + | |||
| + | === Creating Testrunner Environments === | ||
Documentation based on Igor's mail to kde-pim ML: | Documentation based on Igor's mail to kde-pim ML: | ||
| Line 28: | Line 30: | ||
</config> | </config> | ||
</code> | </code> | ||
| + | |||
| + | === Using the Testrunner === | ||
| + | |||
| + | ==== Interactive Use ==== | ||
After that you only needs to run the testrunner: | After that you only needs to run the testrunner: | ||
| Line 38: | Line 44: | ||
And right now you have a self contained Akonadi server. | And right now you have a self contained Akonadi server. | ||
| + | |||
| + | ==== Non-Interactive Use ==== | ||
| + | |||
| + | ''kdepimlibs/akonadi/tests'' uses the Akonadi Testrunner to run unittests in an isolated environment. For automated usage, the testrunner can be used in a non-interactive way: | ||
| + | |||
| + | <code bash> | ||
| + | $ akonaditest -c config.xml <comand> <params> | ||
| + | </code> | ||
| + | |||
| + | The testrunner will run ''command params'' within the isolated environment and terminate afterwards. | ||
| + | |||
| + | This can be used from within CMake (example based on ''kdepimlibs/akonadi/tests''): | ||
| + | |||
| + | <code> | ||
| + | macro(add_akonadi_isolated_test _source) | ||
| + | set(_test ${_source}) | ||
| + | get_filename_component(_name ${_source} NAME_WE) | ||
| + | kde4_add_executable(${_name} TEST ${_test}) | ||
| + | target_link_libraries(${_name} | ||
| + | akonadi-kde akonadi-kmime ${QT_QTTEST_LIBRARY} | ||
| + | ${QT_QTGUI_LIBRARY} ${KDE4_KDECORE_LIBS} | ||
| + | ) | ||
| + | |||
| + | # based on kde4_add_unit_test | ||
| + | if (WIN32) | ||
| + | get_target_property( _loc ${_name} LOCATION ) | ||
| + | set(_executable ${_loc}.bat) | ||
| + | else (WIN32) | ||
| + | set(_executable ${EXECUTABLE_OUTPUT_PATH}/${_name}) | ||
| + | endif (WIN32) | ||
| + | if (UNIX) | ||
| + | set(_executable ${_executable}.shell) | ||
| + | endif (UNIX) | ||
| + | |||
| + | find_program(_testrunner akonaditest) | ||
| + | |||
| + | add_test( libakonadi-${_name} | ||
| + | ${_testrunner} -c | ||
| + | ${CMAKE_CURRENT_SOURCE_DIR}/unittestenv/config.xml | ||
| + | ${_executable} | ||
| + | ) | ||
| + | endmacro(add_akonadi_isolated_test) | ||
| + | </code> | ||
== KNUT Test Data Resource == | == KNUT Test Data Resource == | ||
Contents |
Igor's GSoC project, found in kdepimlibs/akonadi/tests/testrunner. The Akonadi Testrunner sets up an isolated Akonadi server (which implies a separated D-Bus server) based on an environment configuration file.
Documentation based on Igor's mail to kde-pim ML:
First you need create a configuration file in KStandardDirs config resource type (try to use: kde4-config --path config, to find the path in my case the path is /usr/share/kde4/config) , the configuration file is a xml and look like:
<config>
<kdehome>/home/igor/kde/installs/trunk </kdehome>
<confighome>/home/igor/codes/kde/tests/test_akonadi/</confighome>
<datahome>/home/igor/codes/kde/tests/test_akonadi/data</datahome>
<agent>akonadi_ical_resource</agent>
<agent>akonadi_vcard_resource</agent>
<item location="/path/to/file.vcf"
collection="akonadi_vcard_resource_0"/>
</config>
After that you only needs to run the testrunner:
%./akonaditest
and it creates a shell script file in your current directory called testenvironment.sh and you just need to run it.
%source testenvironment.sh
And right now you have a self contained Akonadi server.
kdepimlibs/akonadi/tests uses the Akonadi Testrunner to run unittests in an isolated environment. For automated usage, the testrunner can be used in a non-interactive way:
$ akonaditest -c config.xml <comand> <params>
The testrunner will run command params within the isolated environment and terminate afterwards.
This can be used from within CMake (example based on kdepimlibs/akonadi/tests):
macro(add_akonadi_isolated_test _source)
set(_test ${_source})
get_filename_component(_name ${_source} NAME_WE)
kde4_add_executable(${_name} TEST ${_test})
target_link_libraries(${_name}
akonadi-kde akonadi-kmime ${QT_QTTEST_LIBRARY}
${QT_QTGUI_LIBRARY} ${KDE4_KDECORE_LIBS}
)
# based on kde4_add_unit_test
if (WIN32)
get_target_property( _loc ${_name} LOCATION )
set(_executable ${_loc}.bat)
else (WIN32)
set(_executable ${EXECUTABLE_OUTPUT_PATH}/${_name})
endif (WIN32)
if (UNIX)
set(_executable ${_executable}.shell)
endif (UNIX)
find_program(_testrunner akonaditest)
add_test( libakonadi-${_name}
${_testrunner} -c
${CMAKE_CURRENT_SOURCE_DIR}/unittestenv/config.xml
${_executable}
)
endmacro(add_akonadi_isolated_test)
In kdepim/akonadi/resources, fully featured resource that operates on a single XML file. File format is decribed in knut.xsd and follows closely the internal structure of Akonadi. New files can be created in eg. Akonadiconsole by creating a resource and specifying a non-existing file.
Second part of Igor's GSoC project, currently in playground/pim/akonaditest.
TODO
In kdepimlibs/akonadi/test, part of Robert's thesis.
TODO
Usable without installation, run with ctest/make test as usual.
These tests use the Akonadi Testrunner, the test environment is found in kdepimlibs/akonadi/tests/unittestenv.
The tests do not yet completely work without having certain components installed, namely:
The tests can be run automatically using ctest/make test as usual. To run a single test manually, it needs to be executed using the Akonadi testrunner:
$ cd kdepimlibs/akonadi/test
$ akonaditest -c unittest/config.xml $BUILDDIR/test_executable.shell
Are there any? TODO