Posts Tagged Tessy

Conclusion

Component testing by Tessy is integration testing for the units/functions in the component.

» Read More About Tessy, The Invaluable Test Tool

, , ,

No Comments

Interacting Functions, Temporal Approach

Up to now, time was not an issue, neither for the timely distance of the stimulating calls to a component, nor for the timely distance between a stimulating call to a component and the resulting call to another component. However, it could be an important test to check if such a resulting call happens “fast enough” after a stimulating call, i.e. within a given time frame.

To be able to test the temporal behavior of a component in a simulated environment, a simulated time base needs to be available. This means, a certain function inside the component is called in known equidistant times (e.g. every 10 ms). This is usually the case if the component is executed under the control of a Real-time Operating System (RTOS) with time-slicing, e.g. OSEK. But also a simple self-made interrupt-driven application usually conforms to this requirement.

The calls to this function represent the “heartbeat” of the component. They provide a time reference for the testing of the temporal behavior of the component. (The heartbeat function is usually called “handler function” or “work task” or simply “tick”).

If a heartbeat function exists, timely behavior can be tested.

If a heartbeat function exists, timely behavior can be tested.

Tessy allows very comfortable (drag&drop) to generate scenarios (i.e. component test cases) with references to (simulated) time.

Scenario with temporal reference

A scenario with temporal reference (with results)

In the above scenario initially the component function init() is called to initialize the component. At 20 ms simulated time, the component function set_sensor_door() is called with its parameter set to “closed”. Resulting from this stimulus, the external function LightOn() is called at 30 ms simulated time. This has happened as expected what is indicated by the green tick mark. At 60 ms simulated time, the variable sensor_ignition (a global variable of the component) is set to “on”. At 80 ms simulated time, at the end of the scenario, the value of the variable state_light (also a global variable of the component) is checked. The value is “off”, what is as expected.

, , , , , , , , ,

No Comments

Single Function

A single function is the smallest reasonable test object of a C program and is usually considered to be a unit. Unit testing is functional black-box testing, i.e. it is based on the interface of the function (i.e. input/output variables and called functions). Unit testing is dynamic, i.e. the test object is executed.

Unit Test

During unit testing the test object is tested in isolation from the rest of the application

If the function under test calls other functions, during pure unit testing, the calls to these functions are replaced by calls to stub functions.

Testing of a single function (i.e. unit testing) is the functionality of many unit testing tools including Tessy and will not be discussed further here.


, , , , ,

No Comments

Hierarchy of Functions

A hierarchy of functions can be tested in a manner very similar to the test of a single function by taking the top-level function as the test object, and considering the called functions as to be inside the test object.

Hierarchy of functions

A hierarchy of functions takes the top-level function as test object.

This is technically achieved by not replacing the called functions by stub functions. You may still consider this as unit testing as above, but for bigger units.

It can also be considered as integration testing for the functions in the hierarchy, because they have to work together correctly to pass the tests, at least to some extent. Such a hierarchy of functions could also be called a module, but this term should not be confused with a C source module of a C program. (A C source module is not automatically an appropriate test object for module testing, as it is defined syntactically, whereas a module for module testing is defined semantically.)

The testing of a hierarchy of functions is technically very similar to the testing of a single function. Testing of a hierarchy of functions is the functionality of many unit testing tools including Tessy and will not be discussed further here.

, , , , , , ,

No Comments

Testing of Software Components

This page discusses the testing of software components. To approach the term “component testing”, we need also to discuss the terms “unit testing”, “module testing”, and “integration testing”. We assume the software to be written in C. The definition of the terms is based on the type of the possible test objects.

The topic is illustrated by referring to the features of Tessy, a tool to automate unit / module / integration testing of embedded software.

Read on:


, , , ,

No Comments