Expected results and Stack usage

The table Expressions can contain expressions, which are evaluated after the test execution ends. All valid C expressions can be used.
We can test the following data:

function return value, for example: rv == 34
variables declared in the variables section, for example: *ptr == 42
target global variables
target registers by using prefix '@', for example: @R3 == 42
IO module inputs by using back quotes as a prefix, for example: `DigitalIn.DIN0 == 1

See also the tool tip of the table (place mouse cursor over the table header).

Exceptions

Some languages support exceptions for error handling. If option Expect target exception is selected, then testIDEA handles exception as an expected test outcome. This can be used for example, when we want to test error handling in our code. To evaluate thrown exception object, internal variable isystem_test_exception can be used in the Expressions table.

Stack usage

Stack memory is always a limited resource, and problems related to overlapping data and stack region are hard to find, and can produce everything from strange non-reproducible target behavior to fatal crashes.
With testIDEA we can measure and test amount of stack used by code executed in test. The information is not retrieved from debug info, but it is measured by counting unmodified stack memory locations.

To measure stack usage, we must first configure stack addresses and seeding pattern in testIDEA File | Properties | Stack usage page:

Stack base address (baseAddr) is the lowest address we expect to be used for stack, and Stack end address (endAddr) is the last address - top of the stack, usually stack pointer is set to this value at target init.
If we expect less stack to be used during test that it is actually available, we can enter higher base address - test will still pass, but execution will be a bit faster since less memory needs to be analyzed.

Seeding pattern is a byte value written to unused stack area. testIDEA reads stack memory area after test, and considers locations with other values to be used for stack during test.

Once we've configured stack measurements, we can specify the maximum allowed amount of stack used for each test:

Test reports contain also amounts of stack used before the test started, amount used by testIDEA for test local variables, and the actual amount used by application code under test.

Limitations

Seeding pattern

Since the pattern used for stack initialization can occur also in normal program execution, this approach may not be 100% accurate in all cases. However, probability that it will give wrong results for more than few bytes is very small, and depends also on selection of seeding pattern in File | Properties | Stack usage. It is recommended to use a pattern, which can not be valid address. For example, if our target has no memory or other addressable items at 0xCCCCCCCC, then 0xCC is a good choice.

Stack overflow

testIDEA can measure stack usage under normal conditions, when there is still some space on the stack left. Stack overflows will not be detected. This is normally not a problem for unit tests, as single function usually uses much less space than there is used during normal application run.

Recursion

Stack usage in case of recursion heavily depends on values of input parameters, so successful tests of recursive functions do not guarantee limited stack usage.