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

thesis: Commas

Browse Source
This commit is contained in:
Lorenz Stechauner
2025-08-24 17:38:31 +02:00
parent f4e816d769
commit 5016718283
4 changed files with 19 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -4,11 +4,11 @@
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.
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'').
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.
This work uses simple sockets to communicate between the process of the program to be tested and a ``server'' which decides what action to perform for each function call.
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.
This work uses simple sockets to communicate between the process of the program to be tested, and a ``server'', which decides what action to perform for each function call.
Currently, only communication over Unix sockets is implemented, but communication over TCP sockets is also easily possible.
Figure~\ref{fig:control-flow} illustrates the control flow for manipulating function calls.
@@ -97,10 +97,10 @@ The contents of this message type correspond to the second line of an intercepte
\section{Automated Testing using Function Call Manipulation}\label{sec:automated-testing-using-function-call-manipulation}
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.
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, 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.
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).
@@ -113,7 +113,7 @@ In reality, there are multiple failing paths, each for every possible error retu
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.
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.
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?
Or what if the ``cleanup'' path is very complex and includes function calls not priorly marked as valid cleanup functions?