Encapsulating other test types in redtests
Because redtests are completely generic, it is quite easy to encapsulate other types of tests in it. For this paragraph, we will take the case of microservice bindings tests.
For more information about the application framework, bindings and binder, please refer to the “Developer Guides”.
The test framework for the microservice bindings uses LUA language to describe tests. To learn more about this framework, go to the “Binding Tests” chapter of this documentation. It includes everything needed to write tests for your binding.
The “Spec File example” section gives an example of spec file generating three packages: helloworld-binding, helloworld-binding-test and helloworld-binding-redtest. Some redpesk® macros allow one to easily build a package and its “test” and “redtest” subpackages from the spec file.
Once the packages are built, the helloworld-binding-test sub-package contains the actual tests to run, when the helloworld-binding-redtest contains only the run-redtest executable that makes the right calls to the test framework. In this case, the helloworld-binding-redtest has a dependency on the helloworld-binding-test since it uses it to run the tests.
In the redpesk infrastructure, the spec file macro named %afm_package_redtest takes care of this dependency.
A full tests encapsulation can be found in the example project named helloworld-binding.
At the root of this project, two directories are dedicated to test: ./test and ./redtest. They correspond respectively to the helloworld-binding-test and helloworld-binding-redtest sub-packages.
Inside the ./redtest directory can be found two files:
-
run-redtest.in : it is a cmake template used to generate the run-redtest script that the redpesk infrastructure runs on target during the test process. For this package, the template looks like that:
#!/bin/bash
BINDING_NAME="@BINDING_NAME@"
BINDING_TEST_NAME="@BINDING_TEST_NAME@"
AFB_TEST_BINDER="afbtest"
# Get the name of the test binder
TEST_BINDER=$(afm-util list -a | jq -r .[].id | grep ${AFB_TEST_BINDER})
# Get the name of the package inside afb environment
APP=$(afm-util list -a | jq -r .[].id | grep "${BINDING_NAME}$")
# Start the corresponding app if it does not already run
RUNNING_APP=$(afm-util ps | jq -r .[].id | grep $APP)
if [ -z "$RUNNING_APP" ]
then
afm-util start $APP
fi
# Get the binding test name
TEST_BINDING=$(afm-util list -a | jq -r .[].id | grep ${BINDING_TEST_NAME})
# Launch the test included in the package
afm-util start ${TEST_BINDING}
# Create the directory where the logs need to be
mkdir -p /var/log/redtest/${BINDING_NAME}/
# Copy the logs from source to new location
cp -a /home/`id -u`/app-data/${BINDING_TEST_NAME}/* /var/log/redtest/${BINDING_NAME}/
# Assigns the correct rights
chmod 770 -R /var/log/redtest/${BINDING_NAME}/
chown root:users -R /var/log/redtest/${BINDING_NAME}/
# Stop the app that we were testing
afm-util terminate $APP
- CMakeLists.txt: it contains the different instructions to create the run-redtest script from the template and to install it. For this package, the template looks like that:
###########################################################################
# Copyright 2015 - 2020 IoT.bzh
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
###########################################################################
set(BINDING_NAME "helloworld-binding")
set(BINDING_TEST_NAME "helloworld-binding-test")
configure_file(run-redtest.in run-redtest @ONLY)
install(PROGRAMS ${CMAKE_BINARY_DIR}/redtest/run-redtest
DESTINATION /usr/libexec/redtest/${BINDING_NAME}/)
So, a user wanting to build a “redtest” package for its own binding, needs to write its tests under a “/test” directory and then copy
Current limitation
- For the moment, the only available target for testing is a x86_64 virtual target (i.e. simulated targets based on QEMU).