2

I would like to run unit tests for some ESP32 code I'm writing via the ESP-IDF development framework in VS Code. My unit tests require some simple mocks for the related esp32 components (esp-wifi, esp-netif, etc.). My unit test workflow involves Clang as my compiler.

Here's my problem: I need to include functions, classes, structs, enums, etc. from the ESP-IDF when building my tests. I would like to include the header files from the ESP-IDF, however that results in an awful web of dependencies that spans throughout the ESP-IDF. Even if I end up including all required header files from the ESP-IDF, I end up also needing system includes from the xtensa-esp32-elf toolchain, which ends up clashing with my standard system includes for my clang compiler.

My current solution is to just copy only the prototypes, structs, enums, etc. that I really need from the relevant ESP-IDF header files, then place those in a set of "ESP-IDF-spoofing" mock headers. I can ensure the dependencies don't travel too far by replacing definitions with stub-like replacements (using wifi_osi_funcs_t = int). This is tedious, doesn't scale well, and results in some latent bugs when I unwittingly use a type that I think is the real thing but rather I forgot I just stubbed it a long time ago.

Some possible solutions I have considered are:

  1. Precompiling all of the ESP-IDF header files I need together via the xtensa-esp32-elf toolchain, then use that precompiled header with the clang compiler to build my tests. I'll be honest; I have never precompiled header files, nor do I have a great grasp of why one would or when that would be useful. My lack of familiarity with this path is why I have created this Stack Overflow account today (long time lurker!). I'm sure it would take a good number of hours to try that solution, and I'd like to avoid that if it's a nonsensical choice.
  2. Using some sort of cross compiler that will allow me to compile esp32 projects to run on my computer. This also feels like a bit of a longshot, and I don't love this option because I feel like I'll find myself using gcc over clang in this case. I'd really prefer to stick with clang for writing my unit tests, as it's already quite integrated into my standard workflow.
georgev93
  • 21
  • 1
  • 1
    It's a gnarly problem. I've found no good solution to the same problem, except to replace in my code the entire ESP IDF API with shim layers that forward the small subset of function calls that I use to the real API (there's likely 30-40 functions total). I re-use only the few data types from ESP IDF that those shims require, which are then easier to isolate and copy into bare-bones header files. I end up with unit tests mocking the 30-40 shim functions, using the isolated data types. Not very scalable, but manageable. – Tarmo May 24 '23 at 15:47
  • 1
    Well at least it's good to know I'm not alone! There are dozens of us, I'm sure – georgev93 May 25 '23 at 10:17

0 Answers0