I’m afraid I don’t get any error from that simple demo… the test ran just fine for me. I also don’t seem to be seeing any main code builds unless specifically doing one.
> Executing task in folder Mini_Framework: platformio test --environment native <
PIO Plus (https://pioplus.com) v2.4.0
Verbose mode can be enabled via `-v, --verbose` option
Collected 1 items
=================================================== [test/*] Building... (1/2) ===================================================
=================================================== [test/*] Testing... (2/2) ===================================================
0 Tests 0 Failures 0 Ignored
========================================================= [TEST SUMMARY] =========================================================
test/* > uno [IGNORED]
test/* > native [PASSED]
=================================================== [PASSED] Took 0.61 seconds ===================================================
One way to do platform specific could would be to start using #defines. i.e., the below is a main.cpp that would build for either native or Arduino … although in this case it’s basically two separate programs in one source file. I use something similar though for code that runes on both Arduino Uno or ESP8266 though, and just needs a few bits changed.
You could add extra defines for say Windows, Linux, Mac… if you wanted to detect the other OSs, based on your platformio.ini environment… i.e.
build_flags= -D WINDOWS for a windows environment…
Serial.println("Hi, I'm an Arduino! I'm cute and cuddly!");
cout << "This ain't no stinking Arduino!" << endl;
I’ve not really played with the unit testing, as I haven’t really worked out how it would fit in my current development workflow (or lack of one). After playing around with it for a minute now, it looks like when you do a test, instead of building what’s in your
/src folder, it seems to be building whats in the
/test folder? So if your test has an
#include <Arduino.h> in it, but you’re testing against
native… that is doomed to fail. So you’d either need to use the test_ignore parameter to ignore test code that is platform specific, or perhaps use defines to disable any platform specific bits of the code.