GlossaryΒΆ

API
Short for Application Programming Interface. The interface a piece of software provides to other software to use for programming purposes.
cross-compiling
The act of compiling software on one architecture, i.e., a personal computer, for another architecture, i.e., an embedded system.
cross-testing
The act of testing a system under test on one device (the test host) while executing it on another (the target device).
DFE
DResearch Fahrzeugelektronik GmbH. The company which develops MONK.
embedded system
A computer highly adapted to a specific usecase, often used inside cars, trains, airplanes, etc.
extended INI
A text format based on the INI format, that also allows nesting.
fixture
Short for test fixture.
fixture file
A file that contains data in extended INI format. It will be read by a Fixture object.
INI
A traditional text file format consisting of sections that contain key-value pairs of data. Used often for configuration files and description of relational data.
Jenkins
A CI server that continuously builds your software projects, runs test suites and builds documentation from source.
MONK
This is the framework you are reading the documentaion from, right now!
nose
A Python tool to run unit tests. See its PyPi page: nose.
open source
Software that can be used and developed without the need to pay license fees first. The usage here is broader than the combination of the defintion of Free Software by the Free Software Foundation and the defintion of Open Source by the Open Source Initiative.
PIP
the package manager for Python packages. Often used together with virtualenv to create independently managed projects.
regression test
A test that is created for the purpose of being run many times, e.g., every night or after every change to a system.
reST
reST is the short form of restructuredText, which is a markup format for text files.
shell command
A command that can be executed by a shell, typcially bash. Shell commands are sent when interacting with a target device remotely via serial connection or ssh.
SUT
An abbreviation of system under test.
system under test
The system of hardware and software that should be run in a test. It can be very small like a function or really big, like a network of servers. It completely depends on the test case. It is good practice to call the system under test SUT in test scripts.
target device
A device that you interact with remotely to test it. In our case it is a embedded system that is configured to do a specific task which will be tested in our test cases. A MONK test always requires two computers. A target device and a test host.
test case
A test case is a set of test fixture, actions, verification steps, and clean up steps that run one specific test.
test fixture
The system under test and its surrounding environment in specificially defined state (as far as it is possible).
test framework
A well maintained test scripting project consists of two parts. One part are the test scripts themselves and the other part is a test framework of helper classes and functions that should help in clarifying the test code and take care of some of the complexity.
test host
A computer that runs your test suites for you. It does not contain the system under test though. This would be the target device. A MONK test always requires both a target device and a test host.
test scripting
writing tests in a programming language. Other ways of testing software could be record&replay or manual testing.
test suite
A set of test cases that is run together.
unit test
In general a unit test is the lowest level of testing, verifying a specific unit of a system for one detail of functionality. In open source development the term is often used for all kinds of tests that are written with a unit test framework. This also includes integration tests, regression tests, etc. In this documentation the second definition is used.
virtualenv
A tool that creates independent Python environments in which Python packages can be installed, removed or updated depending on manual usage of the package manager pip, and via requirements.txt files.

Previous topic

The Package

This Page