lorenz.stechauner/BSc-Thesis
1
0
Fork 0
Code Activity

thesis: Apply proofreading suggestions

Browse Source
This commit is contained in:
Lorenz Stechauner
2025-08-19 12:35:54 +02:00
parent 30121e4543
commit 8712bdc461
7 changed files with 32 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
thesis/src/03.manipulate.tex
View File

@@ -4,7 +4,7 @@
This chapter discusses how to manipulate function calls and how this may be used to test programs.
How function calls may be intercepted at all is discussed in Chapter~\ref{ch:intercepting-function-calls}.
This chapter builds on the basis of the previous one and expands its functions.
``Manipulation'' in this context means to change the arguments of a function then calling it with those changed arguments, or skipping the execution of the real function completely and simply returning a given value (``mocking'').
In this context, ``manipulation'' means changing the arguments of a function before calling it with the modified arguments, or skipping the execution of the real function completely and simply returning a given value (``mocking'').
These techniques allow in-depth testing of programs.
In contrast to simply recording and logging function calls which may be controlled via environment variables, manipulation of such function calls requires some other process to indicate how to handle each call.
@@ -98,7 +98,7 @@ The contents of this message type correspond to the second line of an intercepte
As seen in Figure~\ref{fig:control-flow} function call manipulation allows for mocking individual calls.
Mocking may be used to see how the program behaves when individual calls to function fail or return an unusual, but valid, value.
The simplest way to automatically test programs is to run them multiple times and on each run let a single function call fail.
The simplest way to automatically test programs is to run them multiple times, allowing a single function call to fail in each run.
The resulting sequence of function calls now may be put together to a call sequence graph (or tree).
By analyzing this call graph, it is possible to decide if a program correctly terminated when faced with a failed function call.
This may be the case when the following function calls differ from those which were recorded on a default run (without any mocked function calls).
@@ -112,7 +112,7 @@ Edges labeled with ``fail'' indicate the next function call after a mocked faile
In reality, there are multiple failing paths, each for every possible error return value, but in this example they all yield the same resulting path, therefore, they have been collapsed.
To test, if a programmer always checked the return value of a function and acted accordingly, this resulting call sequence graph now may be analyzed.
This test seems trivial at first.
At first glance, this test appears trivial.
The simplest approach is to verify that after a failing function call only ``cleanup'' function calls (\texttt{free}, \texttt{close}, \texttt{exit}, \dots) follow.
For simple programs, this assumption may hold, but there are many exceptions.
For example, what if the program recognizes the failed call correctly as failed but recovers and continues to operate normally?