Testing a model with client/server
communication is often a challenge. During our trip to India, Wolfgang and I wanted to share some thoughts about this
topic right in front of the Taj Mahal. Hi Wolfgang! Hi Nabile! True, this can be a challenge. If we implement a client or a server runnable, the communication
partner is often missing. This can happen because it's a thirdparty
component or a basic software service. However, we need some counterpart to be able to simulate
a communication between
them. Yes, indeed.
The communication is comparable to a function call, so the server provides
a function which the client can call. But then, if we have the client without
the server functionality, how do we test? In general, we have two options
to provide the server functionality. Either we have a copy of the server behavior that we can reuse
or we create a sub implementation. The most common stubbing approach is to connect stub variables to the function
arguments of the server. Okay, so if the
client calls the server
to get the data, we can control the data via a stub variable connected
to the output argument of the server. And if the client sets a data,
then we can read the information via a stub variable connected
to the input argument of the server. Yes, exactly. And if the server implements a bi- directional communication (get & set),
we can have as many sub variables as needed to connect
to the respective arguments. But how does it look like
for the test environment? Well, we ca
n automatically create the model that connects
the server and the client. However, we need to make sure that the new
model enables us to test model and code. This is possible with appropriate
model configurations. The model can then generate the stubs
in a separate set of source files, which can integrate with the actual
AUTOSAR production code. So it's all these to enable
SIL simulation. Okay, and this is similar when
we test the server runnable. Since the logic of the interfaces
of the server
already implemented, we just need a caller mechanism
that mimics the client. So Nabile, what about the test cases? How do they look like? Well, they just look like any regular test cases with input and output signals, at
least in a tool like BTC EmbeddedTester. No matter if the signal relates to a stub variable, a server argument,
or a sender/receiver port, the test case automatically shows
abstract input and output interfaces, and the connection to AUTOSAR or non-AUTOSAR communication is manage
d in the background, respectively
for MIL and SIL. Alright, that doesn't sound too difficult. So I think this provides a smooth
and less error prone test setup. So if you liked this video,
give us a like. Follow us on LinkedIn and YouTube for more videos.
Comments