TESSY - Technical FAQs

Principally, there are two possibilities: Either the user provides the called subroutine, or TESSY does. If TESSY provides the called subroutine, TESSY generates a so-called “stub” function. TESSY provides two kinds of stub functions: stub functions, in which the user may insert C code; and stub functions, where TESSY checks the value of passed parameters and provides input to the function under test.
If the user provides the called subroutine, it can be done either in source form or in binary form. If the user provides the called subroutine, this is the first step away from module / unit testing towards integration testing.

Yes. Let two different functions under test both call the same subroutine. TESSY allows having the first function under test use a different stub function than the second function under test. This refers not only to the behavior of the stub function, but also to the kind of stub function (user code vs. parameter check).

Yes. If a function under test calls a subroutine implemented in the same C source module than the function under test, normally, the linker automatically links that subroutine. However, special handling by TESSY allows having a stub function for the called subroutine in the case at hand.

Yes. The behavior of the stub function can be differentiated dependent e.g. on the test case number. If the same stub function is called several times during a test case execution, the stub function can return different values on each call. An application note exists on the latter topic.

Yes. This feature is called “Call Trace”. It is even possible to check that a certain stub function is not called.

All ANSI-C types like structures, arrays, unions, pointers etc. can be input or output (or both). Of course, the types can be nested, e.g. structures containing pointers pointing to other pointers, linked lists, etc. The more complex a variable is, the more benefit arises from using TESSY. Additionally, non-ANSI-C data types like bit, which are often found in embedded programs, are supported.

The parameters of the function and global variables (both variables global to the module and variables global to the program; both external and non-external variables) may be input or output or both. If a pointer points to a non-allocated memory area, TESSY can allocate memory for it. Naturally, the return value of the function is output in every case.

If the test is executed on the target hardware, the normal interaction with the hardware registers is maintained, i.e. the microcontroller-internal and -external hardware is included in the tests.
If access to the actual hardware is not wanted, access to the hardware registers can be replaced by access to variables (SFR substitution).
TESSY can also "simulate" the hardware registers by checking values written to and supplying values read from the peripheral registers (SFR). This is quite comfortable if the hardware access is made through dedicated functions, because these functions can be easily replaced by stub functions.

Yes. Normally, functions in C preceded by the keyword static are only visible in the C source module where they are defined. This hinders calling static functions from the outside, what is normally required for testing purposes. However, special handling by TESSY enables unit testing for static functions.

Yes. However, this needs to be enabled especially.

TESSY can test the logic/algorithmic behavior of interrupt function by disabling the interrupt functionality for that function, i.e. by treating the interrupt function as a normal function.

Yes. TESSY is able to permute and combine user specified values for interface variables to generate tests. Also ranges of values can be specified. This allows for a very quick and convenient generation of a huge amount of tests.

Yes. The Test Data Editor is able to set variables to random values.
It is also possible to import random test data from an external source (e.g. an Excel sheet).
 However, TESSY provides the Classification Tree Method, which is intended to determine systematically a minimal set of error-sensitive test case specifications. The main idea behind the method is to carefully select test cases and test case data, what is opposite to using randomly generated test data.

No.
With regard to output values: It is possible and it makes sense to do an (initial) test run without having specified the expected results. After the first run, you may check the results and take the resulting values as expected values for consecutive test runs. This is useful if you test e.g. a sorting algorithm, where you can check the sorted result at a glance instead of manually determining the result and then entering it manually.
With regard to input values: It would make no sense to run a test case with undetermined input values. However, TESSY is able to treat any input variable as "irrelevant" and you can run the test without specifying a value for it.

The actual output data is compared to the expected data. Not only equality, but also inequality, ranges and tests for greater than, less than, etc. can be specified. It is also possible to specify a deviation, either in absolute format (e.g. -0.2) or in relative format (e.g. -3%). Both absolute and relative deviations can be allowed either in positive direction (+), or in negative direction (-), or in both directions (w/o sign). It is also possible to test single bits of the output data and ignore the value of the other bits. The evaluation can also be suppressed, i.e. it yields o.k. for any output value.

Test cases group test steps, so that several tests are conducted in a certain order. This is most useful, if internal states of a test object shall be maintained between the test steps. Hence, if a test object needs an initialization, or if a test object resembles a state machine, the test step feature provides a solution.

Yes. Both test cases and test steps can be copied.

Yes. Such code can be inserted at various places in the test application, e.g. in the prolog of the test object execution, before each test step, etc. Such code can be used to #include files, to #define macros/constants or to supply data for characteristic curves, etc.

TESSY needs a C interface to the code to test. TESSY cannot recognize variables that are defined using assembler instructions (e.g. ".DB"). Therefore, these variables will not show up in the interface, and therefore, a test case will not include values for these variables.
To test pure assembler code with TESSY, a work-around exists: You may write wrapper functions (in C), that hide the assembler code from TESSY. The tests then are based on this artificial interface. In general, inline assembler code (of C functions) can be tested without problems, because inline assembler code seldom defines variables.

Yes, the test report is extended automatically at the end of each single test run.

Yes, for two reasons:
TESSY parses the source code module and must therefore understand compiler and architecture specific keywords like "bit" or "interrupt".
TESSY compiles and links using an embedded compiler. Therefore, TESSY must know about the compiler and linker (command line options, linker command files, etc.) and the appropriate microcontroller startup code.
A list of supported compilers and architectures is available here.

Yes. Initial support for C++ was implemented in Tessy V2.6. Enhanced support for C++ is available since TESSY V4.0.