How do you structure unit tests for cross-compiled code?
My new project is targeting an embedded ARM processor. I have a build system that uses a cross compiler running on Ubuntu Linux box. I like using unit testing as much as possible, but I'm a little confused on how to proceed with this setup.
I can't see how to run unit tests on the ARM device itself (someone correct me if I'm wrong). I believe the best option is to compile the code on the build machine using your own built-in compiler for unit tests. Is this approach fundamentally flawed? Is unit testing on a different platform a waste of time?
I am planning on using CppUnit on a build machine using my own compiler for unit tests. Then I'll move on to compile the code for the ARM processor and integrate and test the system on the target device itself. How would you structure your source and test code so that it doesn't turn into a convoluted mess?
source to share
When using an embedded device, depends on what interfaces (hardware) you have.
For example, the motion cards I deal with use a command line interface. The IDE they ship uses it as their primary way of interacting with cards. It works the same whether I am using PCI, IDE, Serial, or Ethernet.
The DLL they submit for programming gives access to the command line interface. So I can send a string and read the response. So what I am doing for my unit tests is there is a physical map hooked into (or into) my development machine. I send him commands after downloading the software, read the answer, and if they are correct, he passes the test.
I also have an extra piece of equipment, a black box if you do that, which mimics the car that the motion card would normally control. This helps with auto-dials, but there is a manual phase as I have to set the switches to simulate different settings on the machine.
I have achieved a greater degree of automation by taking a digital I / O board and using its outputs to feed the inputs of the motion control board and the same in the opposite direction.
I found that for most hardware, you must have some sort of simulator hardware.
The exception is a rare package that comes with a software simulator.
I know this is not ideal as not every developer can have one of these on their desk. My hardware simulator, so I can give it to someone who was working on motion control software at the time. If it can't be portable, then having a dedicated computer for testing or developing hardware will be fine.
Finally, it comes down to the specifics of your hardware and the support that the manufacturer provides in terms of software and simulations. To help you more, you will need to post more details.
source to share
In my ten-plus years in the embedded industry, I've seen quite a few do this. In my current company:
- one of our products has enough power (and space) to run tests on a target board. It is somewhat slow and we cannot insert the whole python into the field we would like, but it works well.
- one of our products has no room, so we build all the libraries we can on x86 (something hardware agnostic) and run unit tests on the desktops. It's not perfect, but much better than nothing.
- one of our components is an ultralight power screenshot on exotic hardware, so it's almost impossible to do one-off tests. Basic algorithms (DES, etc.) are tested on x86 as above, but most of the code just needs to be tested as a whole in place. This entails a lot of code reviews.
source to share