Adds native unit test support, initial test coverage of Utils and Identity#1065
Adds native unit test support, initial test coverage of Utils and Identity#1065aqua wants to merge 30 commits intomeshcore-dev:devfrom
Conversation
Libraries vary on whether they accept a no-argument println(), but they all accept a single string value.
There aren't any standard mocks for these and our code invokes the adafruit LittleFS library and RTC library calls which assume they exist.
Doesn't really add any value over `pio test -e native` but stays consistent with the current build procedure and any -D defines that may become mandatory later.
Uses the native platform, which compiles with the host system's compilers. This was tested on MacOS' GNU c++. Use the skaygin/ArduinoNative libdep for the Arduino platform library dependencies; it's the most complete native mock currently available in PlatformIO and covers almost everything we use. Reuses the preexisting stm32 clone of Adafruit's LittleFS for our filesystem dependency, which seemed to be the easiest path (though it's also the most demanding of the SPI interface.) Uses private mocks of SPI and Wire. The initial two sets of unit tests are fairly trivial, covering our SHA256 library and mesh::Utils::toHex(), just to show that everything's working.
Found the first bug, in fromHex() :)
- printHex (demonstrates a mock/spy stream) - 2-part sha256
It's fast enough (and the current set of tests is small enough) to turn on for the main native env, but not all local compilers will support it so I made it a separate target. Usage: pio test -e native-asan Current tests all pass asan checks.
|
@aqua sorry can you check these conflicts as well? |
|
@446564 Done. Not having gotten any response on the PR I haven't been trying to chase upstream. |
|
Thanks, reviews should start flowing for the next few months. |
|
Which environment should these pass in? I tried with |
- NATIVE_PLATFORM needs the same filesystem open() args as STM32 and NRF52 - Not all Stream implementations have a printf() (fix is simpler anyway)
SensorManager as a virtual interface is fine for testing, but CayenneLPP makes assumptions about Arduino which aren't valid for ArduinoNative and sets up clashes between ArduinoNative and the native C++ libraries (in particular, ArduinoNative wants to #define round, which appears as a symbol in some STL implementations which CayenneLPP will try to fall back on.) Since we're not exercising SensorManager in tests yet, the short-term workaround is to hide the header and forward-declare the class. If we do get to the point of exercising it for testing, the right fix would probably be to send a PR against ArduinoNative to remove that #define as the mainline Arduino libraries did a few years ago.
|
@446564 |
tests are still failing with your most recent commit. |
|
Can you paste your build/test output somewhere ( (I might not respond for a couple days, going to be busy for a bit) |
2 participants
This is an expanded form of PR #925 to address issue #1059 . They overlap but are easily reconciled -- either could be merged and the other updated to adjust for it. This fixes native compilation of almost the entire MC firmware, adds address sanitization, and adds slightly more test coverage. #925 has a couple extra tests I didn't think of, a couple more mocks we might want to merge in for convenient use, and adds a github workflow to run the tests (which is a good idea if maintainers are willing to accept that into the merge workflow -- I'd have done it but held off for feedback.)