Explicitly allow C++ in tests

[yperess]

Introduction

Writing good tests is difficult enough and making sure that there are good common utilities is paramount. With the addition of the gtest twister harness we've enabled the use of it in Twister. Pigweed (yes, I know, that word again) provides a port of gTest that can run in an embedded space. This can drastically and quickly improve our ability to test and is the current plan for our tests in downstream Chrome OS.

The ask

I would like us to update https://docs.zephyrproject.org/latest/develop/languages/cpp/index.html#enabling-c-support to explicitly say that we can use C++ in the tests/ directory.

Appendix

#65278

[thedjnK]

Pigweed

But pigweed was flat out rejected? #53760

[yperess]

Pigweed

But pigweed was flat out rejected? #53760

A) it was rejected on the premises that we didn't have an in tree use. Their port of gTest was very useful to our downstream project and we want to upstream the tests for all the drivers.

B) I'm not asking to add Pigweed. The issue is just saying "allow C++ in tests"

[yperess]

Also, the latest discussion about Pigweed left it open to beeping added as an optional module in #53851. I haven't gotten around to cleaning up that proposal since we changed how modules are loaded

[thedjnK]

Something I really dislike about this idea is it vastly limits devices that can run these tests. Sure native_sim and qemu would be fine, but we have micros with minute amounts of RAM, and some boards/compilers do not even support C++ mode out of the box

[yperess]

@thedjnK is the alternative to just not write them? The way I'm looking at it is this. I have a lot of tests to write; using templates, classes, and lambdas drastically speeds things up and makes it easier to debug. I can either:

A) write the tests in the chromium repo and they'll run to make sure that upstream changes don't break our projects
B) write them in Zephyr and everyone can benefit

Considering that the only tests for sensors in Zephyr were written by Google (AFAICT), I think it's safe to say that others either don't care (or use sensors) or don't have the headcount for it. I don't see why block the option of using C++. I'm not saying all tests should use it. Just that we allow it.

[thedjnK]

If you want to test downstream in C++ then you can do as you like but you're trying to hold a proverbial gun to zephyr by demanding "use C++ for tests or we won't bother having any", without paying due care to what zephyr caters for

Considering that the only tests for sensors in Zephyr were written by Google (AFAICT),

Unrelated to the topic really buy having a look, false. Looks like intel users did most of the contributions

[cfriedt]

I see no reason at all not to explicitly allow tests in C++. Also, wondering if there is some more info on the gtest test harness. I think this is something that Meta might like to use as well.

I started a zephyr shell utility that kind of mirrors gTest in #65437 specifically because someone had forked gtest so that it could be used in zephyr testsuites.

[yperess]

If you want to test downstream in C++ then you can do as you like but you're trying to hold a proverbial gun to zephyr by demanding "use C++ for tests or we won't bother having any", without paying due care to what zephyr caters for

Look, if that's how you want to take it I can't stop you. I'm just saying that this isn't the top priority for me. I'm going to write tests in a way that's fast and efficient. For me that's using C++ ideally using Pigweed + gTest. If Zephyr doesn't want those tests that's fine. I'm not making any threats nor do I mean to. These are the options I'm seeing, I can either put the code upstream and have it benefit everyone or downstream. Not a threat.

Considering that the only tests for sensors in Zephyr were written by Google (AFAICT),

Unrelated to the topic really buy having a look, false. Looks like intel users did most of the contributions

I'm not sure I'm seeing the same git history as you. There are currently 6 emulated sensors only in the Zephyr drivers tree. BMI160, F75303, ICM42688, ADLTC2990, AKM09918C, and AMD_SB_TSI.

Google wrote the emulators for BMI160, F75303, ICM42688, AKM09918C, and AMD_SB_TSI
Zeiss Meditec AG wrote the emulators for ADLTC2990

It looks like a few emulators were written directly into the tests/ directory which makes them impossible to use in downstream testing, but those were for the ina230 and ina237 written by North River Systems Ltd.
Non emulated tests are provided for the ina230 and ina237