ARUnit – Unit Testing of AUTOSAR Software Components

No active maintenance

Please note that ARUnit is currently not actively maintained by the Artop community.

Introduction

ARUnit provides a lightweight testing environment for AUTOSAR software components. It...

...generates an RTE for one individual software component that runs on all major desktop platforms.
...provides an API to stimulate and query the state of the RTE from the outside.
...enables effective and efficient unit-testing of specific SWC functionality.

Why ARUnit?

An AUTOSAR software component always runs inside an AUTOSAR-compliant run-time environment (RTE). What is on the one hand a beneficial standardization of interfaces and of the interaction with the component’s environment is on the other hand an obstacle for unit-testing a single software component. Without a fully functional RTE, a software component’s code basically cannot be executed and tested. However, the increasing size and complexity of automotive software components calls for a continuous and rigorous testing process as early as possible in the development cycle.

How does it work?

ARUnit generates a fully functional, AUTOSAR-compliant RTE for one individual software component. This can be compiled and linked with the actual software component code and runs on all major desktop platforms.

In addition to the component-facing side of the RTE interface, ARUnit also generates a publicly visible API through which the state of the RTE can be monitored and stimulated from the outside, i.e. typically by a test case. This public API follows the same syntactical and nominal conventions as the “internal” API, with the exception that all function names begin with ARUnit_ instead of Rte_. So a typical interaction in a test case looks like this:

UInt8 summand1 = 4;
UInt8 summand2 = 4;
UInt8 expected = 8;
UInt8 result = 0;

// stimulate RTE state from the outside
ARUnit_Write_Calculator_AdditionInput_OperandA(summand1);
ARUnit_Write_Calculator_AdditionInput_OperandB(summand2);

// call SWC runnable
ARUnit_Trigger_Calculator_Cyclic();

// query result state
ARUnit_Read_Calculator_AdditionOutput_Result(&result);

// check expectations
if(result == expected){
	return 1;
}
return 0;

If you prefer a mock-based approach to testing, ARUnit also offers a GMock-based RTE implementation where RTE calls are forwarded to a GMocke'ed C++ class. A typical test case would then look like this:

TEST(Calculator, Addition) {
  Rte_Calculator_Mock rte;
  Rte_Calculator_Mock_Set(&rte);

  UInt8 value = 4;
  EXPECT_CALL(rte, Rte_Read_Calculator_AdditionInput_operandA(_)).WillOnce(DoAll(SetArgPointee<0>(value), Return(0)));
  EXPECT_CALL(rte, Rte_Read_Calculator_AdditionInput_operandB(_)).WillOnce(DoAll(SetArgPointee<0>(value), Return(0)));
  EXPECT_CALL(rte, Rte_Write_Calculator_AdditionOutput_result(8));

  Cyclic();
}

ARUnit Features

Independent of AUTOSAR Version

ARUnit supports AUTOSAR 2.x, 3.x, and 4.x (up to 4.1.1) and generates an RTE for that specific version.

Eclipse/Artop Integration

ARUnit is based on Artop and runs in any typical Eclipse/Artop-based environment. It integrates with the automatic Eclipse build process.

RTE Manipulation API

The API to manipulate the RTE from the outside covers all kinds of input/output interfaces of a software component. It also allows to set delegate functions for server call points so that you can simulate or mock the interaction with another component.

Dynamic Loading and Unloading Of The Component

If you compile your component and RTE code into a dynamic library, it is possible to load a fresh copy of the library into memory before each test case invocation. This basically resets the component into its original state, even if some previous test case has failed and has left a corrupted state in the component implementation.
ARUnit optionally generates code so that this loading and unloading is transparent to your test code.

Extensible Generator Architecture

ARUnit provides extension points to hook custom generators into the generation process. Thereby you can provide additional generation steps, e.g. to produce RTE wrapper APIs in C++ or Python.

Headless Launcher

In addition to the IDE integration, ARUnit provides a separate generator executable that can be launched from the command line. This allows for easy integration with automated build systems.

Limitations of ARUnit

ARUnit provides a limited, bare-bone RTE that implements the API required by a single software component. It does not simulate an ECU or an RTOS. There is no scheduling for runnables and tasks, so for more complex scenarios you will have to manually orchestrate the invocation of runnables.
Since ARUnit focuses on unit-testing of a single software component, we currently do not support compositions.

Get In Touch

The artop team can be reached via or through the mailing list (registration required). Also have a look at our open bugs and feature requests in our Bugzilla.

Additional Resources

Please register or login for additional resources.