Glossary


$declare()

QM code generation directive to generate a declaration of a model element (see QM $declare())


$define()

QM code generation directive to generate a recursive definition of a model element (see QM $define())


$define1()

QM code generation directive to generate a non-recursive definition of a model element (see QM $define1())

to top  

Active Object

An event-driven, strictly encapsulated software object running in its own thread of control that communicates asynchronously by exchanging events (a.k.a. Actor). The UML specification further proposes the UML variant of hierarchical state machines (UML statecharts) with which to model the behavior of event-driven active objects. (see Key Concept: Active Object)


Assertion

A Boolean-value expression evaluated at runtime that is expected to always be true at that point in the code. In C or C++, assertions are the main mechanism for implementing DbC (Design by Contract). In the QP frameworks, customizable and memory-efficient assertions are specified in the qassert.h header file.

to top
to top

CUT

Code Under Test — code being tested.

to top

DbC

Design by Contract — a software design methodology pioneered by Bertrand Meyer, which views a software system as a set of components whose collaboration is based on precisely defined specifications of mutual obligations — the contracts. The central idea of this method is to inherently embed the contracts in the code (ass assertions in C or C++) and validate them automatically at run time. Doing so consistently has two major benefits: (1) It automatically helps detect bugs (as opposed to "handling" them), and (2) It is one of the best ways to document code.

to top
to top
to top
to top
to top
to top
to top
to top
to top
to top
to top
to top
to top
to top
to top
to top
 

Test Assertion

An expression which captures an expectation about the outcome of a test run performed on the CUT. Usually the logic for each test assertion is limited to one single aspect specified. (NOTE: The QUTest harness documentation uses the term Test Expectation instead of Test Assertion to avoid any cofusion between testing and DbC assertions).


Test Double

A collaborator of the CUT that impersonates some function, data, module, or library during test. The CUT does not know it is using a test double; it interacts with the double the same way it ineracts with the real collaborator. Test doubles come in many variants, such as: Test Dummy, Test Stub, Test Spy, Mock Object, Fake Object, Exploding Fake, and others.


Test Expectation

An expression which captures an expectation about the outcome of a test run performed on the CUT. Usually the logic for each test assertion is limited to one single aspect specified (a.k.a. Test Assertion).


Test Fixture

Code that provides the proper environment for a series of test cases that exercises the Code Under Test (CUT). A test fixture will assist in establishihng a common setup and environment for exercising the CUT.


Test Harness

A collection of software and test data configured to test a program unit by running it under varying conditions and monitoring its behavior and outputs (a.k.a. Automated Test Framework). It usually has two main parts: the test execution engine and the test script repository. Test Harness allows for the automation of tests. Example test harnesses useful for testing embedded software are: Unity, CppUTest, and QUTest™.

to top
to top
to top
to top
to top
to top
to top