Unit tests and Mongoose C++ projects

General
#1

I have an existing Mongoose style project where a lot of the code is in C++, I want to be able to run unit tests against this C++ code, ideally running them on every build.

I don’t really know how to organize my project to do this, I suppose at worst case I could use conditional compilation, and figure out how to share code between the existing mongoose style project, and some completely separate external project, but I feel there must be an accepted pattern to do this kind of thing.

I would like to run the unit tests locally in my dev environment, without having to deploy to a target device to execute them.

Part of my struggle is that so much of the Mongoose build environment is “hidden” inside mos.exe, involving remote build and docker images that I don’t really understand what is going on during the build process.

1 Like
#2

Anyone have some insight to share on this one?

I’ve recently been looking at unit testing my mOS project, but having only ever written tests in python, so doing it in C/C++ seems like a bit of a mess from what I’ve been able to work out.

So far the workflow I have is:

  1. write tests in C++
  2. clone GoogleTest suite and compile/install
  3. compile and assemble (gcc) all the .c files I want to test (since my mOS code is in C)
  4. compile and assemble (g++) all the .cpp test files
  5. compile the the lot (g++)
  6. run the test

Would love to hear from someone with some experience on a better/simpler way to get it done

#3

I usually split the project in layers and mock the layers below the one I’m testing. I rarely “unit test a project” but modules.
If you are testing an application then mock all the comms stuff.

#4

Wow interesting, I’ve not even considered being able to do higher level testing on an embedded system.
I’d be really interested in hearing more about this approach if you could share some terminology for me to be able to google or even some links that would be great.

#5

You just think and write your module in a non hardware dependent way, then you can test it wherever you want. I mostly test on Linux (and run on MSP430, Arm Cortex-M0+/M3).
Some people use The robot Framework, some people use Jenkins. So far I’ve managed to be OK with ceedling for the type of work I mostly do.

#6

Yeah I’ve been reading about writing a hardware abstraction layer to decouple hardware interactions from logic, so that the hardware layer can then be easily mocked. Makes sense, I’ll probably need to test mocking in gTest and see how it comes together. Thanks for the tips on the other frameworks that might be better suited to C.

I’ve used RF in the past but only for pure software systems to do acceptance testing. I struggle to imagine how I’d use it for my project.

Yep agreed some type of CI solution like Jenkins or GitHub actions is a must. Personally I prefer GitHub actions since they offer a free tier and it’s cloud.