Skip to content
Klemens Morgenstern edited this page Jul 24, 2018 · 6 revisions


This framework provides facilities for automated execution of remote code (e.g. on an embedded controller). It is built around the debugger, so that compiler facilities can be used to obtain information. The current state provides functionality for:

  • I/O Forwarding
  • Code Coverage
  • Unit testing
  • Call tracing
  • Profiling

This is based on a plugin-system so that it can be extended with functionality for your system. The above features are also done by plugins that are provided by the framework. Since it is built to use the debugger, it can be used for every case a debugger can, which includes the following applications:

  • local execution
  • remote server (gdbsever)
  • openocd
  • qemu

When used with the right plugins, an application run via openocd or qemu behaves as if it were run locally and can be integrated into any automated testing.

It currently only supports the gdb, but lldb support is planned for a future version.

Tool overview


The runner is the core module of the toolest, it allows automated execution of the debugger. This can be used with plugins, so that custom functionality can be added to breakpoints. The main application is for the automated executing tests on remote targets, such as embedded platforms. It comes with two plugins for embedded targets:

  • I/O (similar to semi-hosting)
  • Exit-Code

When used with these two plugins an embedded application can be run on the target, but behaves as if it were run locally. In addition, the calltrace & backend provide part of the functionality as part as runner plugins.


We provide a very lightweight unit test library, for use with the metal.runner. When used without the debugger, it will only yield a binary result, while it will provide very detailed information through the debugger. This means that it can be used with the same assertions in hosted as well as standalone mode.


The calltrace provides a way to assert a certain call sequence for functions. Combined with the metal.runner it can be used to log function calls and add profiling.


For debugger-less applications, e.g. scenarios that only have byte output through a serial-port, metal.serial provides low-level test library. It works by minimizing the output of the actual application and retrieving all possible data from the source files.

You can’t perform that action at this time.