Software/Unit Testing on Embedded Hardware (C++, CAN)

Technical Support
, , , ,
1

Hey guys,

we are currently working on a bigger software project, developed on your hardware and are slowly approaching a point where it might be useful to start using software tests to debug our software.

I’ve never used software tests on embedded hardware before and was wondering if you have any recommendations or best practices to write software tests for embedded systems or more specifically your hardware.

We are using C++ to interact with multiple CAN and Modbus/TCP Interfaces with libraries like libmodbus and libsocketcan, so we would also need a way to mock/fake these interfaces in our test conditions.

Thank you!
Lukas

Used Hard- and Software:
Colibri iMX6ULL 1GB on Colibri Eval Board
Torizon Core 6.3.0

2

Hi @xlukem,
this is a very interesting topic, thanks for asking these questions :slight_smile:

so we would also need a way to mock/fake these interfaces in our test conditions.

There are two approaches to this:

  1. As you mentioned, mocking and purely software testing: for that, I can recommend something like gMock with a test step in your application Dockerfile, that contains the compiled tests. In the test setup, you can initialize these mocks as well as any dummy interfaces you need (for CAN you could do something like this, for example networking - How can we create multiple dummy interfaces on Linux? - Unix & Linux Stack Exchange).
    In the test itself, you’d listen to those interfaces and interact with them through your application and see if the result matches. This can be easily ported to a CI pipeline as a test stage as well.

  2. Testing with hardware-in-the-loop: you can leverage the same test step in your container with your compiled tests but this time testing on the actual device instead of using the mock interfaces. To get automated feedback and actuate the board you could use something like paramiko for ssh access paired with pexpect to check if the outputs match expectations. For this, of course, you’ll need to have a dedicated testing infrastructure with a board on a shelf somewhere and a “controller” that will listen/actuate the board.

It really depends on how your team is organized, and if there is easily accessible infrastructure and time dedicated to building this infrastructure.

1 Like