Running unit tests from Atmel Studio 6

Question

I am currently developing an embedded c++ project in Atmel Studio 6. This project has a fairly significant embedded portion and also a significant business logic portion. Ideally I would like to run some unit testing for the business logic code. Being able to conveniently build then run these tests would make it more likely that the unit tests get used.

If I try to compile with the Boost unit tests with the default avr-gcc compiler I get errors because various header files cannot be found. I understand that these headers are not implemented for the AVR chipset I am using as they would be too expensive in that context. However these headers are only ever used for unit testing the non-embedded part and have therefore been placed in their own dedicated unit tests project.

Will I need to set up a different compiler to compile the unit tests? Is it possible to compile the unit tests with a different compiler toolchain to the default avr-gcc installed or will I have to compile the unit tests elsewhere? Is there an easier way of doing this?

Answer 1

When I build embedded software I sometimes write unit tests over the (hardware independent) business logic, and run them on my host x86 architecture.

I normally build an Eclipse CDT (or Qt Creator) project over the same source tree, accessing the folder where you have your C++ logic, and compiling it alongside with the unit testing framework and the test cases with gcc, targeting x86 architecture. Eclipse or Qt Creator will handle the Makefiles for me. You can use Boost or any other unit testing framework here; I normally need just 50 lines of code I provide myself, with a few assert functions (this way you can use the same unit tests in the final AVR architecture, for example).

I normally provide ant tasks for building the embedded software for AVR, and building and passing the unit tests for x86, so I can easily integrate it with a continuous integration panel.

Good luck!.

Answer 2

In cross-platform projects it's common to have more than one set of toolchains. Problems when building on one of the platforms mean that the code has not been ported correctly on one of the platforms (I'm sure you already knew this part).

What you usually do is add in compile time switches and rewrite the problematic code. For example any references to boost library(on the code for Win) will cause problems on the embedded target. So you have to take those out using compile time, machine dependent, switches . You may have to rewrite some modules because of this but then again that is why you don't use 3rd party libraries of libraries which have not been ported to your desired architecture(like boost) in cross-platform code.

Since we are talking unit tests here, you may be able to get away with simply printing some output to files when running on the platform and than have a windows based script/program parse them an interpret the results - this strategy applies for 90% of unit tests in on embedded platforms (it also addresses the problem of real time which comes with most embedded projects).